この記事は連載『AIに仕事を奪われる不安から始めるハーネス作成入門』第24回（最終回）です。
連載目次
| 回 | タイトル | 状態 |
|---|---|---|
| 第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回 | モデルルーターの疑似コードでLLM切替を設計する | ✅ |
| 第13回 | AIハーネスにログ設計が必要な理由 | ✅ |
| 第14回 | AIエージェント実行ログをMarkdownとJSONで残す | ✅ |
| 第15回 | Human-in-the-loopはどこに入れるべきか | ✅ |
| 第16回 | Slack承認を想定したハーネス処理フローを描く | ✅ |
| 第17回 | AI時代でもSEの品質保証経験が価値を持つ理由 | ✅ |
| 第18回 | MCPサーバーの単体テスト・結合テスト観点を作る | ✅ |
| 第19回 | 機密情報をLLMに渡さないハーネス設計 | ✅ |
| 第20回 | プロンプト投入前のマスキング・復元フローを設計する | ✅ |
| 第21回 | ハーネス作成をポートフォリオ化する方法 | ✅ |
| 第22回 | Qiita連載とGitHubリポジトリを連動させる運用 | ✅ |
| 第23回 | AIハーネスを副業・受託・社内改善に転用する前に考えること | ✅ |
| 第24回 | 12週間のハーネス連載を振り返り、次に作るAI基盤を決める | ✅ |
はじめに ── 12週間で何が変わったか
第1回の「仕事を奪われる不安」から始まったこの連載も、ついに最終回を迎えました。振り返ると、12週間で大きく3つの変化があったのではないでしょうか。
- 「不安」が「判断基準」に変わった: AIへの漠然とした不安が、「何をどう制御するか」という具体的な判断基準に変わりました
- SE経験が「活きる」と実感できた: テスト、ログ、CI/CD、設計書──SEが培ったスキルがそのままハーネスに転用できました
- 「作れる」から「届けられる」への道筋が見えた: ポートフォリオ化・運用・転用と、キャリアへの接続パスが見えました
連載で学んだことの棚卸し
フェーズ1: 基礎編（第1〜8回）
| テーマ | 学び |
|---|---|
| ハーネスの考え方 | AIを「制御する」視点が重要 |
| 環境構築 | 小さく始めて育てる |
| プロンプト設計 | テンプレート化で品質安定 |
| バリデーション | LLM出力は必ず検証する |
| エラーハンドリング | 失敗前提で設計する |
| ログ・コスト | 運用を見据えて作る |
フェーズ2: 応用編（第9〜16回）
| テーマ | 学び |
|---|---|
| テスト・CI/CD | 自動化で品質を守る |
| プロバイダー層 | 柔軟なアーキテクチャ |
| MCP | ツール連携の標準化 |
| ワークフロー | 複雑な処理を管理する |
| A/Bテスト | データで改善する |
| 設定外部化 | 変更に強い設計 |
フェーズ3: 実践編（第17〜24回）
| テーマ | 学び |
|---|---|
| マルチエージェント | 分割と協調の設計 |
| モニタリング | 可視化で運用を安定 |
| デプロイ | 届けるための設計 |
| マスキング | データ保護の実装 |
| ポートフォリオ | 見える化の技術 |
| 転用 | キャリアへの接続 |
次期ロードマップ
連載で学んだことを土台に、次のステップとして考えられるAI基盤プロジェクトのロードマップを描きます。
| フェーズ | 期間目安 | やること | 判断基準 |
|---|---|---|---|
| 0. 棚卸し | 1週間 | 連載で作ったコードを整理・リファクタリング | テストが通る状態にする |
| 1. 特化 | 2週間 | 自分の業務ドメインに合わせたハーネスを構築 | 実業務で使える状態 |
| 2. 実証 | 2週間 | 小規模な実データで検証 | 効果を数値で示せる |
| 3. 展開 | 4週間 | 社内提案または副業として提供 | 他者が使える状態 |
| 4. 拡張 | 継続的 | フィードバックを受けて改善 | リピーターがいる |
ロードマップの使い方
このロードマップは「正解」ではありません。自分の状況に合わせてカスタマイズしてください。
- 時間が限られる人: フェーズ0と1を丁寧に、フェーズ2以降は無理のないペースで
- すぐに展開したい人: フェーズ1を2と並行で進める
- まずは学びを深めたい人: フェーズ0で連載コードを彻底的にリファクタリング
次に学ぶべき技術領域
連載ではカバーしきれなかった領域もあります。次のステップとして検討してみてください。
| 領域 | 内容 | こんな人におすすめ |
|---|---|---|
| RAG | ドキュメント検索とLLMの組み合わせ | 社内ドキュメントを活用したい |
| Fine-tuning | モデルのカスタマイズ | 特定ドメインの精度を上げたい |
| エージェントフレームワーク | LangGraph, CrewAIなど | 複雑なワークフローを作りたい |
| セキュリティ | プロンプトインジェクション対策 | セキュリティを深く学びたい |
| MLOps | モデルのライフサイクル管理 | 本番運用を見据えている |
連載を終えて
12週間、全24回の連載にお付き合いいただき、ありがとうございました。
この連載は「仕事を奪われる」という不安から始まりました。でも実際にやってみると、AIは「仕事を奪うもの」ではなく、**「仕事のやり方を変えるもの」**だとわかります。
そして、その変化を「制御」する技術がハーネスです。SE経験で培った「品質を守る」「安全に運用する」「ドキュメントで伝える」というスキルは、AI時代にこそ一層価値があります。
不安は消えないかもしれません。でも、不安を「行動」に変えた経験が、この12週間で生まれたはずです。その経験は、次の一歩を踏み出すときに必ず力になります。
コミュニティへの案内
連載は終わりますが、学びは続きます。以下の場所で引き続き情報発信を行います。
- Qiita: AIハーネス関連の単発記事を不定期に投稿
- GitHub: ハーネスコードのアップデートを継続
- コメント欄: 質問やフィードバックはいつでも歓迎です
まとめ
- 12週間で「不安」が「判断基準」に変わった
- SE経験の**「守る力」「届ける力」がそのまま活きる**
- 次期ロードマップで、自分のペースで次の一歩を
- 不安を行動に変えた経験が、一番の資産
この記事は連載『AIに仕事を奪われる不安から始めるハーネス作成入門』第24回（最終回）です。
全24回の連載にお付き合いいただき、ありがとうございました。
引き続き、QiitaとGitHubでAIハーネスの情報を発信していきます。