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回を振り返る	─

連載：AIに仕事を奪われる不安から始めるハーネス作成入門

著者: @singula00991｜週2回更新

次回は「ハーネス用のディレクトリ構成とREADMEを作る」を予定しています。