はじめに
GMOコネクトの平島です。
Claude Codeを業務で使い始めてしばらく経ち、簡単なタスクは安定して任せられるようになりました。一方で、設計書を書かせる・複雑なデータ加工を頼むといった「判断が多い」タスクは、ざっくり投げると毎回違うアウトプットが返ってきて😇となります。
- ざっくり「これお願い」で投げたら、触ってほしくないファイルまで書き換えられた
- 出力フォーマットが既存ドキュメントと揃わず、毎回手戻りが発生する
- 「あれも書いて」「これは削って」を何往復もして、結局自分で書いた方が速かった
原因はだいたい「指示の曖昧さ」です。とはいえ、毎回完璧な指示書を手で書くのもしんどい。そこで、指示書の作成自体をAIに任せる、というワークフローに落ち着きました。
私が業務で使っているワークフローはこんな感じです。
- メタプロンプト: AIエージェントに「別のエージェントへの指示書」自体を書かせる → 着手前に論点を出し切れる
-
構造化指示:
Goal / Constraints / Acceptance criteriaの3点で標準化する → 触ってよい範囲・完了条件が固定される - スキル化: 成功した指示パターンを再利用可能な資産として保存する → 次回以降は一言で同じ品質が出る
AIを「都度チャットで相談する相手」から、「規約に沿って動く実行系」へ寄せていく、という発想です。
出発点: ある複雑な設計タスク
きっかけは、社内のセキュリティレビュー指摘への対応方針を、実装可能な粒度の設計書に書き起こす、というタスクでした。盛り込むべき要素はざっと7項目あります。
- ツール選定の根拠（採用案 / 不採用案の比較）
- 設定・ポリシーの調達方針と配置先
- CIへの組み込み設計
- ローカル／コミット前チェックの設計
- レビュー運用との連携
- 工数見積もり（区分ごと）
- 段階導入の方針
このボリュームをそのままAIに投げると、よく次の事故が起きます。
- 参照元ファイルを直接編集してしまう（設計書として別ファイルに起こすべきだった）
- 既存の社内ドキュメントとフォーマットが合わない（命名規約、見出しスタイル、章立てがバラバラ）
- 推測で断定して書いてしまう（読み手が真偽を判定できない）
これらは「Constraintsとして最初から固定しておけば防げる」種類の事故です。だからこそ、指示書を雑に書くより、着手前に時間をかけて指示書そのものを設計した方が結局はラクです。
Step 1: メタプロンプト — AIに指示書を作らせる
最初の一手は単純です。「依頼するための指示書」をAIに書かせるだけ。
依頼文はこんな感じです。
〇〇.md の修正内容の設計を行いたい。エージェントに指示するためのプロンプトを下記フォーマットで出力してください。
Goal: <達成したいこと> Constraints: <守るべき制約> Acceptance criteria: <完了の判定基準>
ポイントは、AIが書き始める前に対象ファイルやリポジトリを実際に読み込んで事実を集めることです。これがあるとないとで、出来上がる指示書の質はだいぶ違います。「現状のCIはこういう構成になっています」「既存のフォーマット規約はこうです」といった事実を Constraints に前提化してくれるので、受け手のエージェントは追加質問なしで着手できます。
実際に生成されたプロンプトはこんな形になります（一部抜粋・一般化したもの）。
Goal:
〇〇.md の「対応方針」セクションを、実装可能な粒度の設計に書き起こす。
設計に含めるべき要素:
1. ツール選定の根拠（採用案 / 不採用案の理由）
2. 設定・ポリシーの調達方針と配置先
3. CI への組み込み設計：既存ジョブへの追加ステップ案
4. ローカル／コミット前チェックの設計と導入手順
5. レビュー運用との連携
6. 工数見積もり（CI 組み込み・ローカル整備・既存コード是正の3区分）
7. 段階導入の方針（warning運用 → ブロッキング化）
Constraints:
- 対象ファイル 〇〇.md のみを編集。既存の「前提」「指摘事項」「推奨事項」セクションは改変しない。
- 実コード（CI設定ファイル等）は変更せず、設計記述に留める。コード片はコードブロックで提示するに留める。
- 現状を正しく前提化すること：既存CIのジョブ構成・ステップ順序・トリガ条件を明記。
- 推測で断定せず、未確定事項は [要確認] と明示する。
- 日本語で記述し、既存ファイルの見出しスタイル（## 見出し）に合わせる。
Acceptance criteria:
- Goal の 1〜7 を網羅した設計記述になっている。
- CIへの追加ステップが、既存ステップとの位置関係を含めて具体的に提示されている。
- ローカル検証手順とエンジニア向け導入手順が記載されている。
- 工数が3区分で見積もられている。
- ツール採用判断の理由が、対象システムの特性と紐づけて1〜2文で説明されている。
- [要確認] 項目が箇条書きで列挙されている。
- ファイルがMarkdownとして崩れず、既存セクションが保持されている。
このプロンプトはそのまま別セッションに貼り付けて使う前提で書かれています。
Step 2: 3セクション構造がなぜ効くのか
Goal / Constraints / Acceptance criteria の3点構造、これは思いつきの形式ではなく、役割が明確に分かれていることが効きます。
| セクション | 役割 | よくある失敗 |
|---|---|---|
| Goal | 達成したい「結果」を書く。手段は書かない | 「〇〇を使って△△を実装」と手段に踏み込みすぎて、より良い手段の選択肢を潰してしまう |
| Constraints | 触ってはいけない範囲・既知の前提・出力フォーマットを固定する | 当たり前と思って書かないと、AIは平気で逸脱する |
| Acceptance criteria | 完了したかを客観的に判定できる条件 | 「いい感じに仕上げる」のような曖昧条件にすると、レビューが永遠に終わらない |
実務上いちばん効くのは Constraints です。「現状のシステムはこうなっている」「既存のこのファイルは触らない」「未確定の事項は [要確認] と書いて残す」といった事実の前提化を明示するだけで、受け手のエージェントの誤認が激減します。
ちなみに、このフォーマットは私のグローバル設定（~/.claude/CLAUDE.md）にも書いてある「非自明タスクの前置きフォーマット」と揃えています。依頼側と実行側で同じ語彙を使うと、認識のズレが起きにくくなります。
Step 3: スキル化 — 成功パターンを資産にする
ここまでで、1回うまく動くメタプロンプトが手に入りました。次の課題はこれです。
次のタスクで同じことをやるとき、また同じ品質のメタプロンプトを書けるか？
普通にやると、毎回少しずつフォーマットがブレます。前回は「output/ に保存」していたのに、今回は会話の流れで別の場所に出してしまう。前回は [要確認] を使っていたのに、今回は別の記号を使う。こうした小さな揺らぎが積み重なって、再利用性が下がっていきます。
そこで、1回うまくいったプロンプト生成の手順をスキルとして固定化します。Claude Codeのスキル機能であれば、こういう中身のMarkdownを所定の場所（~/.claude/skills/<name>/SKILL.md）に置くだけで、トリガーワードによる自動発動が効くようになります。
スキルの中身として書いておくのは、おおむね次のような要素です。
- トリガー例: 「〇〇のプロンプトを作成して」「エージェント指示プロンプト」など
-
出力フォーマット: コードブロック形式、英語ラベル（
Goal:/Constraints:/Acceptance criteria:）、本文は日本語 - ワークフロー: 対象把握 → 3セクション設計 → ファイル出力 → 報告、の4ステップ
- 各セクションを書くときの判断基準: Goalには手段ではなく結果を書く、Constraintsには調査済みの事実を前提として明記、Acceptance criteriaはGoalの各要素に対応させる
-
保存先の規約:
output/配下にMarkdownで保存、ファイル名規約 -
注意事項: 推測で断定しない、未調査の前提を書かない、
[要確認]を明示する
これで「〇〇のプロンプト作って」と一言投げるだけで、調査→3セクション設計→ファイル出力→レビュー論点提示まで、同じ品質で動くようになります。
Before / After
実際に同じ種類のタスクを「直接依頼」と「メタプロンプト経由」で進めた感触を比較すると、こんな違いがあります。
| 観点 | Before（直接依頼） | After（メタプロンプト経由） |
|---|---|---|
| 誤った範囲への変更 | 参照元のファイルを直接編集してしまうなどの事故が起きる | Constraints で触らない範囲が固定されているので発生しない |
| フォーマットの統一 | 既存ドキュメントを後から見直して合わせ直す手戻りが発生 | 着手前に「既存スタイルに合わせる」がConstraintsに入っている |
| 未確定事項の扱い | AIが推測で書いてしまい、レビューで真偽判定に時間がかかる |
[要確認] で明示されるのでレビューポイントが事前に分かる |
| やり取りの往復 | 「あれも書いて」「これは違う」が何度も発生 | 着手前にAcceptance criteriaで条件を出し切れているので往復が少ない |
| 次回の再現性 | 毎回ゼロから依頼を考える | スキル発動の一言で同じ品質が再現される |
特に大きいのは「着手前に論点を出し切れる」という効果です。直接依頼だと、AIが書き始めてからやっと「あ、これは指示が足りていなかった」と気付くケースが多いのですが、メタプロンプトを挟むと生成された指示書をレビューする段階で論点が浮かびます。やり直しのコストが圧倒的に小さい。
応用: 設計タスク以外でも使える
このワークフローは設計タスク専用ではありません。**「曖昧で、複数の判断を伴い、出力フォーマットの規約がある」**作業全般に効きます。
たとえば、
- Excelやスプレッドシートの整形作業: 入力シートのどの列を、出力シートのどのセルに、どの形式で入れるか
- データ加工・集計: 入力データの前処理ルール、欠損値の扱い、出力フォーマット
- ドキュメントの転記・要約: 元ドキュメントのどの章を、どの粒度で、どの文体で書き直すか
- コードリファクタリング: 触る範囲、命名規約、互換性を保つべきインターフェース
いずれも、「事前に決めておけば防げる手戻り」が多いタスクです。3セクション構造に落とせば、AIが暴走する余地が小さくなります。
落とし穴と運用Tips
実際に運用してみて分かった注意点も書いておきます。
1. AIに書かせた指示書を鵜呑みにしない
メタプロンプトの段階で人間が一度レビューを入れるのが大事です。AIは事実調査を頑張ってくれますが、それでも見落としや誤解はあります。「Constraintsに書かれている前提は本当に正しいか？」「Acceptance criteriaは漏れていないか？」を確認するワンクッションを置くと、後段の事故がぐっと減ります。
2. 調査の質が指示書の質を決める
メタプロンプトの段階でAIが手抜きをして調査せずに書くと、Constraintsが推測ベースになり、結局後段で破綻します。スキル化するときに「対象ファイルは必ずReadする」「関連リポジトリ構成を確認する」といった調査ステップを明示しておくと、品質が安定します。
3. スキルのトリガー文言は具体的にする
「プロンプト作って」のような曖昧なトリガーだと、意図せず発動しなかったり、別のスキルと競合したりします。「エージェント指示プロンプト」「Goal/Constraints形式」のような特徴的なフレーズをトリガーに含めると、暴発も誤発動も減ります。
4. 出力先・命名規約をスキル内で固定する
「保存先は output/ 配下」「ファイル名は 【対象名】_エージェント指示プロンプト.md」のように決め打ちにしておくと、後で生成物を見返すときの探しやすさが段違いです。
おわりに
AIエージェントを使い始めると、最初は「思った通りに動かない」もどかしさにぶつかります。ここで「プロンプトを練り直す」方向だけで戦おうとすると、人間側の負担が際限なく増えていきます。
そうではなく、
- 指示書をAIに書かせる（メタプロンプト）
- 構造化フォーマットで標準化する（Goal/Constraints/Acceptance criteria）
- 成功パターンを資産にする（スキル化）
この3段でAI側の自走範囲を広げる方が、長期的には圧倒的にラクです。1回うまくいったパターンが翌週も翌月も同じ品質で再現される、というのは想像以上に効きます。
似たような依頼を繰り返している領域があれば、まずは「次回の自分のために指示書をAIに書かせる」ところから試してみるとよいかもしれません。
参考記事
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。