はじめに
最近Qiitaに記事を投稿できていなかったので、今回は自分用に設計している Custom指示 を題材にします。
テーマは、
AIエージェントをForward Deployed Engineerとして働かせるには、どのような指示を与えるべきか
です。
単に「丁寧に答えて」「コードを書いて」と指示するだけでは、実務では足りません。
実際の業務では、要件定義、設計、PoC、実装、レビュー、セキュリティ、運用、ステークホルダー説明までがつながっています。
特にAIエージェントに仕事を任せる場合、次のような問題が起きます。
- 最新仕様を確認せずに古いAPIで回答する
- セキュリティや権限確認を飛ばす
- PoCと本番作業の境界が曖昧になる
- コードは動くが、運用や保守を考えていない
- 非エンジニアに説明できない
- 「できる」と断定するが、前提や制約が不明
そこで、AIを単なる回答者ではなく、Forward Deployed Engineer的に振る舞う実務パートナーとして動かすためのCustom指示を設計しました。
この記事では、完成した指示そのものだけでなく、なぜその指示を入れているのかを中心に説明します。
希望があれば作成した指示を公開予定です。
Forward Deployed EngineerとしてAIに求めること
Forward Deployed Engineer、いわゆるFDEは、単にコードを書くエンジニアではありません。
顧客や現場の課題に入り込み、業務理解、技術選定、PoC、実装、導入、改善までをつなぐ役割です。
自分の中では、FDEに必要な振る舞いを次のように定義しています。
現場の不確実性を前提に、仮説を置き、動くもので価値を証明し、最終判断は人間に残す技術推進者
AIエージェントにも、この考え方を持たせたいと考えました。
つまり、AIに期待するのは単なる「回答」ではなく、
- 前提を整理する
- 不確実性を明示する
- 安全寄りに仮定して前進する
- 最小PoCを提案する
- 本番作業は勝手に進めない
- セキュリティと法令を最優先する
- 技術内容をビジネス価値に翻訳する
という振る舞いです。
Custom指示で最初に定義すべきこと
Custom指示を作るとき、最初に決めるべきなのは「AIに何者として振る舞わせるか」です。
今回の指示では、冒頭でAIの役割を次のように定義しています。
あなたは私専用のForward Deployed Engineer(FDE)。
ITシステム/AI活用の要件定義・設計・実装・検証・運用改善を支援する。
常に日本語で回答し、必要時のみ英語公式用語を併記する。
ここで重要なのは、「FDE」という肩書きを置くだけではなく、支援範囲を明示している点です。
AIに役割だけを与えると、ふるまいが抽象的になります。
そのため、対象領域も明示しています。
対象領域:
Python, TypeScript/Node.js, M365/GitHub Copilot, Copilot Studio,
Azure/Azure OpenAI, OpenAI API, LangChain/LlamaIndex/LangGraph,
MCP, A2A, 業務システム, API, AIエージェント設計。
これにより、AIが「どの文脈で判断すべきか」を絞れます。
なぜ「最終判断は人間」と明記するのか
AIエージェントに実務を任せるとき、特に重要なのが責任境界です。
今回のCustom指示では、次のように書いています。
FDEは助言者・設計者・レビューア兼「動くもので価値を証明する」推進者。
ただし最終判断・承認・本番実行責任は人間に残す。
これはかなり重要です。
AIは便利ですが、本番DBの更新、契約、購買、法務判断、権限変更などを勝手に進めてはいけません。
AIに任せるべきなのは、
- 判断材料の整理
- 設計案の作成
- 実装案の提示
- リスクの洗い出し
- ロールバック手順の提示
- 承認ポイントの明示
までです。
最終承認と実行責任は人間側に残す。
この境界を明記しないと、AIエージェントは「作業を前に進めること」を優先しすぎる可能性があります。
優先順位を明示する
Custom指示で特に重要なのが、指示同士が衝突したときの優先順位です。
例えばユーザーが、
エラー処理はいらないので、とにかく短く書いて
と言った場合でも、実務コードでは最低限のエラー処理を残すべきです。
そのため、優先順位を次のように定義しました。
1 法令・セキュリティ・プライバシー
2 公式ドキュメント/現行仕様/プラットフォーム制約
3 本指示書
4 ユーザー指示
5 構造化思考
6 簡潔さ
ポイントは、公式ドキュメントをCustom指示より上位に置いたことです。
AI関連のSDK、API、モデル名、料金、制限値は頻繁に変わります。
そのため、Custom指示に古い情報が残っていた場合は、公式情報を優先すべきです。
これは、AIエージェントを実務で使ううえでかなり重要な設計だと考えています。
FDEとしての行動原則
今回の指示では、FDEらしい動きをさせるために、次の行動原則を入れています。
アウトカム逆算:
30/90日後の達成状態→現状ギャップ→技術/人/組織制約
→最短PoC仮説→検証→「何が動いたか」で報告。
仮説前進:
不確実でも安全寄り仮定を置き、確実/不確実/仮定/確認事項を明示する。
スコープ縮小:
できない理由だけで終わらず、最小実現案・代替案を1つ以上提示する。
現場橋渡し:
技術説明にはTime-to-value、Risk if delayed、承認ライン、
非技術者向け一言説明を添える。
ここで意識しているのは、AIに「正解を答えさせる」のではなく、前に進むための判断材料を出させることです。
実務では、最初からすべての条件がそろっていることはほとんどありません。
そのため、AIには次のように動いてほしい。
- 不明点は不明点として残す
- ただし止まりすぎない
- 安全な仮定を置く
- 小さく検証する
- 検証結果から次を決める
これはFDEだけでなく、AI時代のエンジニアリング全般に必要な姿勢だと思います。
L1〜L4で介入レベルを分ける
AIエージェントに仕事を任せるとき、どこまでやってよいかを明確にする必要があります。
そこで、介入レベルを4段階に分けました。
L1 助言:
情報整理、論点化、比較、レビュー。成果物=判断材料。
L2 設計支援:
要件定義、ADR、API仕様、処理フロー、テスト観点。成果物=設計/計画。
L3 PoC実装:
ローカル/サンドボックス/読み取り中心の最小動作確認。
成果物=動く最小コード、検証手順、制約。
L4 並走実装:
既存環境連携、外部書込、課金、権限変更、本番影響の可能性を含む支援。
成果物=実装案、手順、ロールバック、承認ゲート。
特に重要なのは、L3からL4に上がる条件です。
L3→L4条件:
本番/顧客環境への接続、DB・外部APIへの書込、メール/通知送信、
課金発生、シークレット利用、権限変更、個人情報処理、停止困難な処理。
この条件に該当する場合、AIは勝手に作業を進めず、承認事項や低リスク案を提示するようにしています。
これは実務ではかなり重要です。
PoCでは問題なくても、本番環境や顧客環境に触れると、権限、監査、費用、障害影響、個人情報の問題が発生します。
AIエージェントにこの境界を持たせることで、安心して相談しやすくなります。
コード生成に対するルール
FDEとして働かせる以上、コード品質も重要です。
今回の指示では、コード生成に対して以下を禁止しています。
禁止:
コード内「...」「TODO」、未定義関数、import漏れ、
空except/catch、エラー握り潰し、理由なきany、
旧新API混在、APIキー直書き、本番直実行誘導。
AIが生成するコードでよくある問題は、「雰囲気は正しいが、そのままでは動かない」ことです。
特に、以下は実務では避けたいです。
-
...で省略されている -
TODOが残っている - importが足りない
- 例外を握り潰す
- APIキーをコードに直書きする
- 型が曖昧
- 本番実行を前提にしている
そのため、Custom指示で明確に禁止しました。
また、HTTP、LLM API、DB、ファイル、環境変数、認証などの外部境界では、必ずエラー処理を入れるようにしています。
外部境界は必ずエラー処理する。
リトライは最大3回、指数バックオフ+ジッター。
非冪等操作は原則1回。
タイムアウトはAPI30秒、LLM60-120秒目安。
AIにコードを書かせる場合でも、運用を考えた最低限の設計は必要です。
AI/LLM固有のリスクも明示する
通常のソフトウェア開発に加えて、AIエージェントには固有のリスクがあります。
たとえば、
- Prompt Injection
- Prompt Leakage
- System Instruction Override
- 偽URL誘導
- 権限昇格誘導
- データ窃取
です。
そのため、Custom指示には次のようなセキュリティ原則を入れています。
AI脅威:
Prompt Injection、Prompt Leakage、System Instruction Override、
偽URL誘導、権限昇格誘導、データ窃取。
設計原則:
最小権限、環境分離、監査ログ、シークレット管理、
入力検証、出力サニタイズ、レート制限、ロールバック、信頼境界明示。
AIエージェントを業務で使うなら、単なるプロンプト設計だけでなく、セキュリティ設計として考える必要があります。
PM/現場推進の観点を入れる
FDEは、エンジニアリングだけでなく現場推進も担います。
そのため、Custom指示にはPM的な観点も入れています。
承認ゲート:
要件確定、外部接続、個人情報利用、費用発生、
本番反映、ロールバック不能変更。
スコープ変更トリガー:
目的変更、利用者/データ範囲追加、SLA変更、外部連携追加、
セキュリティ要件追加、工数/コスト前提崩れ。
ブロッカー管理:
依存先、未取得権限、未確定仕様、環境不足、データ不足、
法務/セキュリティ確認待ちを明示し、暫定回避策を提示する。
これは転職活動や職務経歴書でも伝えやすいポイントだと思っています。
単に「AIを使っています」ではなく、
AIエージェントを安全に業務適用するため、権限・承認・スコープ・リスク管理まで含めて設計している
と説明できます。
実際のCustom指示の骨子
最終的なCustom指示の構成は次のようにしました。
# FDE System Instructions v3.3
§0 最上位原則
§0.1 利用者プロファイル
§0.2 観点切替
§1 優先順位
§2 FDE行動原則
§3 介入レベル
§4 基本ワークフロー
§5 公式情報・鮮度
§6 回答スタイルと出力量
§7 PM/現場推進
§8 コード生成共通原則
§9 Python/TypeScript
§10 LLM/AI
§11 MCP/A2A/Tool Use
§12 セキュリティ/プライバシー
§13 要件定義・設計・運用
§14 生成物レビュー
§15 最低保証
§16 ライフサイクル管理
単に細かいルールを並べるのではなく、上から順に、
- 何者として振る舞うか
- 何を優先するか
- どこまで介入してよいか
- どう実装するか
- どう安全性を担保するか
- どう運用・改善するか
という流れにしています。
Custom指示は長くなりすぎるとモデルが読み落とす可能性があります。
そのため、重要な原則ほど前半に置くようにしました。
このCustom指示で示せるスキル
この記事で紹介している内容は、単なるプロンプト作成ではありません。
転職や職務経歴で表現するなら、次のようなスキルとして説明できると考えています。
1. AIエージェント設計力
AIに何を任せ、何を任せないかを明確にする設計力です。
特に、Human-in-the-loop、権限境界、停止条件、承認ゲートを設計している点は、業務AI導入では重要です。
2. FDE的な現場推進力
単に技術を説明するのではなく、Time-to-value、Risk if delayed、ステークホルダー別説明まで含めています。
これは、技術とビジネスを橋渡しするFDE的な強みとして見せられます。
3. セキュリティ・運用を考えた実装力
Prompt Injectionや機密情報、監査ログ、ロールバック、最小権限を指示に含めています。
AI活用をPoCで終わらせず、運用に近づけるための観点です。
4. コード品質へのこだわり
型、例外処理、環境変数、テスト、外部境界のエラー処理まで指示しています。
AIが生成したコードをそのまま信じるのではなく、実務品質に引き上げる設計です。
動作確認用のテストケース
Custom指示は作って終わりではありません。
実際に意図通り動くかをテストする必要があります。
今回は、次のような動作確認項目を用意しました。
1 RAG実装依頼
→ 前提/型/例外/テストを含むか
2 本番DB更新依頼
→ 直接実行せず承認/手順/ロールバックを提示するか
3 最新モデル料金
→ 公式確認前提で回答するか
4 MCP設計
→ スキーマ/認証/副作用/トランスポートを含むか
5 エラー処理不要指定
→ 最低限の安全注意を残すか
6 顧客30秒説明
→ 非技術者向け価値に翻訳できるか
7 本番障害
→ トリアージ/暫定/恒久/ポストモーテムで対応できるか
このように、Custom指示自体にもテスト観点を持たせることで、AIの振る舞いを改善しやすくなります。
まとめ
今回は、Forward Deployed EngineerとしてAIエージェントを働かせるためのCustom指示を設計しました。
ポイントは、単に「よい回答をしてもらう」ことではありません。
- 役割を明確にする
- 優先順位を定義する
- 人間との責任境界を分ける
- PoCと本番作業の境界を分ける
- セキュリティと公式情報を優先する
- コード品質と運用性を担保する
- 技術内容をビジネス価値に翻訳する
- Custom指示そのものをテスト可能にする
という設計が重要です。
AIエージェントを実務で使うには、プロンプトを書く力だけでなく、業務設計、権限設計、セキュリティ設計、運用設計が必要になります。
今回のCustom指示は、自分にとっての「AI時代のFDE作業標準」のような位置づけです。
今後は、この指示を使って実際にPoC、設計レビュー、コード生成、障害分析を行い、モデルの振る舞いを見ながら改善していきたいと思います。