PDF の内容を Excel へ入力するような Ops を実現するために、Gemini CLI 用のスキルを作成してみました。
作成したスキル
| スキル | 機能 |
|---|---|
| pdf-to-text | PDF ドキュメントをプレーンテキストに変換 |
| text-to-excel | Markdown テーブルを Excel (.xlsx) 形式に変換 |
これらを組み合わせれば、PDF → テキスト → Excel という変換パイプラインが実現できます。
しかし、デフォルト能力で十分だった
スキルを作成した後に気づいたのですが、Gemini CLI のデフォルト能力だけで同じことが実現できてしまいます。
添付した PDF ファイルを Excel ファイルへ書き出して！
このワンショットのプロンプトだけで、必要なライブラリをよしなにインストールして、PDF の内容を解析し、Excel ファイルとして出力してくれます。
わざわざスキルを事前に作成する必要がなかったのです。
スキル作成の順番を考え直す
従来の自分の考え方は、プロダクト開発と同じでした。小さな機能（スキル）を作って、それらを組み合わせて大きな Ops を実現するというアプローチです。
| ステップ | 内容 |
|---|---|
| 1 | 必要なスキルを設計・作成 |
| 2 | スキルを組み合わせてパイプラインを構築 |
| 3 | パイプラインを使って Ops を実現 |
| 4 | フィードバックを元に改善 |
しかし、AI のデフォルト能力が高い今、この「部品から組み立てる」発想は非効率です。
DCAP サイクル：AI-native なアプローチ
より良いアプローチは、PDCA ではなく DCAP のサイクルです。
| サイクル | 意味 | AI 時代の解釈 |
|---|---|---|
| D (Do) | まず実行 | ゼロベースで実現したいことを Gemini CLI へ依頼する |
| C (Check) | 確認 | デフォルト能力でどこまで実現できたか確認する |
| A (Act) | 改善 | 必要に応じてアウトプットを微調整する |
| P (Plan) | 計画 | 繰り返し使うならスキル化・標準化する |
ポイントは、A (Act) と P (Plan) は必要な場合のみ実行するということです。
- アウトプットに問題がなければ → そのまま完了（スキル化不要）
- 微調整が必要なら → A でフィードバックを繰り返す
- 繰り返し使う Ops なら → P でやり取りのログごとスキル化
なぜ DCAP が良いのか
AI のデフォルト能力が高い今、事前にスキルを作成するのは時間の無駄になりがちです。
| 従来 (PDCA) | AI-native (DCAP) |
|---|---|
| 事前に計画・設計が必要 | まず AI に任せてみる |
| 想定外の問題で手戻り | 実際のアウトプットで判断 |
| スキル作成に時間がかかる | デフォルト能力で即座に実現 |
| 汎用性を意識しすぎる | 具体的なユースケースから逆算 |
DCAP サイクルを回すことで、AI のパワーをフル活用しつつ、本当に必要なスキルだけを効率的に作成できます。
スキル化すべきタイミング
では、いつスキル化すべきなのでしょうか。
| 条件 | 説明 |
|---|---|
| 繰り返し実行する | 同じ Ops を何度も行う場合 |
| 微調整が定まった | AI との対話で最適なプロンプトが確定した場合 |
| 他者と共有したい | チームで同じ Ops を使いたい場合 |
| 品質を担保したい | 一定のクオリティを維持したい場合 |
逆に言えば、1 回限りの Ops であればスキル化は不要です。デフォルト能力だけで十分です。
まとめ
Gemini CLI のデフォルト能力は想像以上に高く、多くの Ops がワンショットのプロンプトで実現できます。
スキルを事前に作成するのではなく、まず AI に依頼してみて、そのアウトプットを確認し、必要であればスキル化する。この DCAP サイクルが AI-native Ops のベストプラクティスだと感じました。
AI の進化とともに、私たちの開発プロセスも変化していく必要がありそうです。
以上、Gemini CLI のデフォルト能力に驚きつつ DCAP サイクルを提唱してみた、現場からお送りしました。