SEの設計経験をAIエージェント制御に転用する
連載：AIに仕事を奪われる不安から始めるハーネス作成入門
全24回（週2回・12週間）｜第5回 / 24
この連載は、AIに仕事を奪われるかもしれないという不安を「ハーネス（AIエージェント制御の仕組み）」を自分で作る行動に変えるシリーズです。
はじめに：この記事で扱う不安
「これまで積み上げてきたSE経験が、AI時代には通用しなくなるのではないか」——この不安を感じたことはありませんか。
新しい技術が登場するたびに「ゼロから学び直し」が必要になるのではないかと考えると、これまでの経験が否定されるような気持ちになることがあります。しかし、結論から言えば、SE経験者が持つスキルセットはAIエージェント制御（ハーネス設計）の分野で大きなアドバンテージになります。
前回（第4回）では、task_request / task_result というAIとの「契約」を定義する考え方を学びました。今回は、その契約を設計する「あなた自身のスキル」に焦点を当てます。
対象読者
- SE・プログラマとして3年以上の実務経験がある方
- 要件定義、設計書作成、コードレビューなどの経験がある方
- AI時代に自分のスキルが陳腐化するのではと不安を感じている方
- 前回までの連載を読んでいる方（未読でも理解できる構成です）
結論
SE経験者が持つ 「要件を整理する力」「責務を分離する力」「仕様を構造化する力」 は、AIエージェント制御の設計にほぼそのまま転用できます。むしろ、これらのスキルがなければ、AIを安全かつ効果的に制御するハーネスは作れません。新しく学ぶべきはAI固有の知識（プロンプト設計、トークン制約など）だけで、設計の土台はすでにあなたの中にあります。
なぜこのテーマが必要なのか
AIエージェント（LLMベースのツール）は、指示が曖昧だと意図しない動作をします。これは、人間の開発チームでも同じです。要件定義が曖昧なプロジェクトが炎上するように、AIへの指示が曖昧だと「暴走」します。
つまり、AIエージェントの制御は「優秀だが文脈を知らない新人エンジニアへの指示設計」と本質的に同じです。SE経験者は、この「指示設計」を日常的にやってきた人たちです。
以下に、SE経験がAIハーネス設計で具体的にどう活きるかの判断基準を示します。
- 「この経験はAI制御に転用できるか？」と迷ったら → 「チーム開発で同じ課題があったか？」を考える
- チーム開発で必要だったスキルは、ほぼすべてAIエージェント制御にも必要
- 違いは「相手が人間か、AIか」だけ
既存のSE / プログラマ経験をどう活かせるか
以下の対応表は、SE経験とAIハーネス設計の転用マップです。今回の主要成果物として、ぜひ保存してください。
| SE経験（スキル） | AIハーネスへの転用先 | 転用のポイント |
|---|---|---|
| 要件定義 | task_requestの設計 | AIに「何を」「どこまで」やらせるかを構造化する |
| 基本設計 / 詳細設計 | ハーネス全体のアーキテクチャ設計 | モジュール構成、データフロー、エラーハンドリングの設計 |
| 責務分離（SRP） | MCPサーバーの分割設計 | 1つのMCPサーバーに1つの責務を持たせる |
| IF設計（API設計） | task_request / task_resultのスキーマ設計 | AIとの入出力契約をJSON Schemaで定義する |
| テスト設計 | AIの出力検証・ガードレール設計 | 期待値の定義、異常系テスト、境界値チェック |
| コードレビュー | プロンプトレビュー・出力レビュー | AI出力の品質確認、プロンプトの改善サイクル |
| ドキュメント作成 | Knowledge MCPへの知識登録 | 設計メモ・仕様書をRAG用に構造化する |
| 障害対応 / 運用 | エラーハンドリング・リトライ設計 | AI応答のタイムアウト、異常応答への対処 |
| プロジェクト管理 | ワークフロー設計・進捗管理 | 複数MCPの連携順序、依存関係の管理 |
全体像：SE経験からAIハーネス設計への転用フロー
以下のMermaid図は、SE経験がどのようにAIハーネス設計に流れていくかを示しています。
具体例：要件定義スキルをtask_request設計に転用する
実際にどう転用するか、1つの例を見てみましょう。
SEとしての要件定義
従来のシステム開発で、外部APIと連携する機能を設計するとき、あなたは以下のことを考えます。
- 入力データの形式と制約（必須項目、型、長さ）
- 出力データの形式と期待値
- エラー時の振る舞い（タイムアウト、リトライ、フォールバック）
- 前提条件と事後条件
AIハーネスでのtask_request設計
AIエージェントへの指示（task_request）を設計するときも、考えることは同じです。
{
"task_request": {
"task_type": "article_generation",
"input": {
"topic": "SEの設計経験をAIエージェント制御に転用する",
"constraints": {
"word_count": {"min": 2500, "max": 4500},
"tone": "不安を煽らない、既存経験を尊重",
"format": "markdown"
}
},
"expected_output": {
"format": "markdown",
"required_sections": ["はじめに", "結論", "まとめ"]
},
"error_handling": {
"timeout_seconds": 120,
"retry_count": 2,
"fallback": "manual_review"
}
}
}
外部API連携の設計経験がある方なら、「これ、やっていることは同じだ」と感じるはずです。違いは、相手がREST APIではなくLLMである点だけです。
実装・設計時の注意点
転用にあたって気をつけるべきポイントを整理します。
| 注意点 | 理由 | 対策 |
|---|---|---|
| AIの出力は非決定的 | 同じ入力でも毎回異なる出力が返る | 出力のバリデーションルールを明確にする |
| トークン制限がある | LLMには入出力の長さ制限がある | task_requestで出力長の目安を指定する |
| コンテキストの喪失 | 会話が長くなると前の情報を忘れる | 重要な情報はtask_requestに毎回含める |
| ハルシネーション | AIが事実でない情報を生成する | 出力の検証ステップを設計に組み込む |
| 過剰な信頼 | 「AIが出したから正しい」と思い込む | レビュープロセスをワークフローに含める |
今回の小さな成果物（チェックリスト）
以下のチェックリストを使って、自分のSE経験の「転用ポイント」を見つけてみてください。
- 上記の対応表を確認し、自分が特に強いSE経験を3つ選ぶ
- 選んだ3つについて「AIハーネスでどう使えるか」を1行ずつメモする
- 最も転用しやすそうなスキルを1つ選び、最初の転用ポイントとする
- 選んだ転用ポイントを「task_requestのどの部分に反映するか」をメモする
- （発展）チーム内で「SE経験×AI活用」の勉強会テーマとして共有する
まとめ
今回は、SE経験がAIエージェント制御（ハーネス設計）にどう転用できるかを対応表で示しました。
キーポイント
- SE経験者のスキルはAIハーネス設計に「そのまま使える」部分が多い
- 特に「要件定義」「責務分離」「テスト設計」は直接転用できる
- 新しく学ぶべきはAI固有の制約（非決定性、トークン制限など）のみ
- 「チーム開発で必要だったスキル ≒ AI制御で必要なスキル」と考えると判断しやすい
あなたのキャリアは無駄になりません。むしろ、AIエージェントを「制御できる側」に回るための最大の武器です。
次回予告
第6回「ハーネス用のディレクトリ構成とREADMEを作る」 では、いよいよ実装に入ります。
扱う内容
- ハーネスプロジェクトのディレクトリ構成案（SE的な観点で設計）
- README.mdの構造と書くべき内容
-
.gitignoreやライセンスファイルなど、最初にセットアップすべきファイル
得られる成果物
- コピペで使えるディレクトリ構成のテンプレート
- README.mdのひな形
試しておくこと
- GitHubアカウントの準備（まだの方は作成しておく）
- 好きなコードエディタ（VS Code推奨）のセットアップ
- 今回の対応表をメモに残しておく（次回以降、設計の指針として使います）
連載目次
| 回 | タイトル | 状態 |
|---|---|---|
| 第1回 | AIに仕事を奪われる不安から「ハーネス作成」を学ぶ理由 | ✅ |
| 第2回 | 最小構成のAIハーネスをMermaidで設計してみる | ✅ |
| 第3回 | AIにコードを書かせるだけでは足りない理由 | ✅ |
| 第4回 | task_request / task_resultでAIエージェントの仕事を契約化する | ✅ |
| 第5回 | SEの設計経験をAIエージェント制御に転用する | 📖 |
| 第6回 | ハーネス用のディレクトリ構成とREADMEを作る | 次回 |
| 第7回 | MCPサーバーを「道具箱」として分割する考え方 | ─ |
| 第8回 | MCPサーバーの最小実装 — FastMCPで最初のツールを作る | ─ |
| 第9回 | RAG / Knowledge MCPがSE経験者に向いている理由 | ─ |
| 第10回 | 設計メモをKnowledge MCPへ登録する前提のMarkdownテンプレート | ─ |
| 第11回 | ローカルLLMを使うべき場面と外部LLMに任せる場面 | ─ |
| 第12回 | 中間レビュー — ここまでの構成を振り返る | ─ |
| 第13回 | エラー分類とリトライ戦略 | ─ |
| 第14回 | ログ設計 — AIの挙動を後から追えるようにする | ─ |
| 第15回 | テスト戦略 — AIの出力をどう検証するか | ─ |
| 第16回 | CI/CDパイプラインにハーネスを組み込む | ─ |
| 第17回 | セキュリティとガードレール | ─ |
| 第18回 | マルチエージェント構成の設計パターン | ─ |
| 第19回 | コスト管理とトークン最適化 | ─ |
| 第20回 | 本番運用への移行チェックリスト | ─ |
| 第21回 | チームへの展開と教育 | ─ |
| 第22回 | 失敗事例から学ぶアンチパターン | ─ |
| 第23回 | 今後の技術トレンドと適応戦略 | ─ |
| 第24回 | 連載まとめ — 不安を行動に変えた24回を振り返る | ─ |
- 著者: @singula00991｜ 週2回更新
次回は「ハーネス用のディレクトリ構成とREADMEを作る」を予定しています。