いよいよ最終章です。ここまでで、あなたはエージェントの構造を理解し、最初の1体を作り、ツールをつなぎ、複数に分け、評価で測り、ガードレールで守るところまで来ました。残るテーマは一つ――それを「毎日動き続ける本番システム」にすること。この章では、フレームワークの選び方、Claudeで作る二つの道、そしてデプロイ・監視・コスト・信頼性という運用の勘所を扱います。前章のガードレールと安全で学んだ守りの設計が、ここで運用として実を結びます。
ゴールは「試作を、安定して動き続ける本番エージェントにする」
自作か、フレームワークか
「エージェントはフレームワークで作るべきか、自分でループを書くべきか」――誰もが最初に迷う問いです。答えはシンプルで、小さいうちは自作で仕組みを学び、育ってきたらSDKやフレームワークで生産性を上げる。第2章で最小構成を手で組んだのは、まさにこの「まず自作で理解する」段階でした。中身が見えていれば、後でフレームワークに載せ替えても、何が起きているかを把握したまま運用できます。逆に、仕組みを知らないままフレームワークに丸投げすると、詰まったときに手が出せなくなります。
💡 判断の目安。 ループ・ツール呼び出し・状態管理を自分で書き続けるのが重荷になってきたら、フレームワーク導入のサインです。逆に、まだ小さく実験段階なら、薄い自作コードのほうが速く、理解も深まります。「便利だから」ではなく「重複が減るから」で入れましょう。
フレームワークの選び方
フレームワークは数多くありますが、名前や最新バージョンを追う前に、「何を基準に選ぶか」の物差しを持つことが大事です。ツールは移り変わっても、この観点は長く使えます。次の5つで候補を評価してみてください。
高いほど少ないコードで動くが、中で何が起きているか見えにくい。学習・デバッグとのバランスで選ぶ。
独自のループや制御を差し込めるか。凝った要件ほど、逃げ道のある柔軟な設計が効いてくる。
連携部品・ドキュメント・事例・コミュニティの厚み。困ったときに情報が見つかるかは実務で効く。
トレース・ログ・評価の仕組みを備えるか。第5章で学んだ「見える化」を、素で支えてくれるか。
特定のモデル・基盤に縛られすぎないか。乗り換えやすさと、囲い込みの利便性はトレードオフ。
代表例をカテゴリで大まかに整理すると、見通しがよくなります。汎用オーケストレーション系（チェーンやグラフでLLM処理を組み立てる、いわゆるLangChain系のライブラリ群）、マルチエージェント系（複数エージェントの分担・協調を主眼に置いたフレームワーク）、そして各社の公式SDK（モデル提供元が出す、そのモデルに最適化された開発キット）です。多くの場合、これらは排他ではなく組み合わせて使えます。
📊 個別名より「観点」で選ぶ。 フレームワークの勢力図は動きが速く、去年の定番が今年もそうとは限りません。だからこそ、上の5観点を物差しに自分の要件へ当ててみるのが確実です。カテゴリごとの具体名と使い分けはAIエージェントフレームワーク比較で最新の顔ぶれを確認してください。
Claudeで作る二つの選択肢
この講座はClaudeを軸にしてきました。Claudeでエージェントを本番化するとき、大きく二つの道があります。どちらも実在の選択肢で、「エージェントのループとサンドボックスを、誰がホストするか」が本質的な違いです。
エージェントのループ・ツール実行・状態管理を、あなたの環境（サーバーやコンテナ）で動かすためのキット。制御が細かく効き、既存システムに深く組み込める。
向く場面: 独自の実行環境・ツール・データに密結合させたいとき。
エージェントのループとサンドボックス（隔離された実行環境）を、サーバー側でAnthropicがホストする方式。実行基盤の運用負担が減り、隔離された安全な環境で動かせる。
向く場面: 実行環境の面倒を減らし、素早く安全に立ち上げたいとき。
おおまかには、自分で細かく制御したいなら SDK、運用の面倒を任せたいならマネージド――という軸で捉えると分かりやすいでしょう。どちらもClaudeの能力を土台に、これまでの章で学んだツール接続・評価・ガードレールをそのまま活かせます。具体的なセットアップや対応範囲は変化しうるので、詳細は解説記事と公式ドキュメントに委ねます。
💡 まず概念、詳細は一次情報で。 「自前でループを回す（SDK）」か「ホストしてもらう（マネージド）」か――この対比だけ頭に入れておけば十分です。実装の手順はClaude Agent SDK 入門、マネージド方式の考え方はマネージドエージェントとはで確認してください。仕様は更新されるので、最終的には公式ドキュメントを一次情報として当たるのが安全です。
本番運用の勘所
試作と本番の違いは、「一度動く」から「動き続ける」への飛躍にあります。デモは何度かうまくいけば成立しますが、本番は毎日・大量・多様な入力に晒されます。ここで効いてくる勘所を、6つの箱で押さえましょう。
環境変数でキーを管理し、設定とコードを分離。再現可能な形（コンテナなど）で出し、いつでも元に戻せるようにする。
第5章の可観測性を本番につなぐ。各ステップのトレース・成功率・遅延を常時見て、異常に早く気づく。
トークン消費を可視化し、上限アラートを設定。無駄な再実行や長すぎる文脈を削り、モデルは用途で使い分ける。
API上限や一時的な失敗を想定し、指数バックオフ（間隔を空けて再試行）で粘る。無限リトライは避け、上限を決める。
会話や作業の途中状態を安全に保存・復元する。途中で落ちても続きから再開できる設計が、長時間タスクを支える。
モデルやSDKの更新は、まず評価セットで挙動を確かめてから。更新前後の比較で、静かな品質変化を見逃さない。
⚠️ コストは"設計"で決まる。 エージェントは1タスクで何度もモデルを呼ぶため、コストが跳ねやすい構造です。安いモデルで足りる工程は安いモデルに回し、文脈は必要な分だけ渡す――こうした地道な工夫が効きます。具体的な削減手法はAIコーディングのコスト最適化が実践的で、エージェント運用にもそのまま応用できます。
崩れないための設計
本番のエージェントは、いつか必ず想定外の入力・外部APIの障害・モデルの気まぐれに出会います。大事なのは「絶対に失敗させない」ことではなく、失敗しても被害が広がらず、静かに復旧できるように組んでおくこと。前章のガードレールを、運用の仕組みとして仕上げましょう。
いきなり全公開せず、少数のユーザーや一部トラフィックから。問題なければ広げ、まずければ即座に戻す。
ツールやモデルが応答しないとき、代替経路や安全なデフォルト応答へ退避。全体停止より部分縮退を選ぶ。
取り消せない・影響が大きい操作の前に、人の確認を挟む（第6章参照）。速度より安全を取るべき境目を決めておく。
一度合格したら終わりではない。入力の傾向もモデルも変わる。評価セットを定期的に回し、品質の劣化を検知する。
✅ 「静かに直る」を設計する。 良い本番システムは、トラブルが起きても大騒ぎになりません。段階リリースで影響を小さく保ち、フォールバックで部分縮退し、承認ゲートで致命傷を防ぎ、再評価で劣化に先回りする。四つが噛み合って初めて「崩れない」のです。
これからの学び
最後に、少しだけ先の話を。エージェントのエコシステム――フレームワーク、SDK、モデル、接続規格――は、これからも猛烈な速さで動きます。今日の最適解が来年も最適とは限りません。だからこそ、追いかけるべきは流行のツール名ではなく、変わらない基礎です。
📊 資産になるのは基礎のほう。 第1章の4つの構成要素（頭脳・道具・記憶・ループ）、第5章の評価と可観測性、第6章の安全設計――これらはどのフレームワークが流行っても通用する土台です。新しい道具が出るたびに、あなたはこの物差しで「これは何を抽象化しているのか」を素早く見抜けます。ツールは移ろい、基礎は残る。ここまで積み上げた理解が、あなたの一番の資産です。
あとは、小さくてもいいので実際に一つ、本番へ出してみること。動かし、測り、直す――このループを自分のプロジェクトで回した経験が、どんな教材よりも力になります。
- 小さいうちは自作で学び、育ったらフレームワークで生産性を上げる。「便利」でなく「重複が減る」で入れる。
- フレームワークは抽象度・自由度・エコシステム・可観測性・ベンダー依存の5観点で選ぶ。個別名より物差し。
- Claudeで作るなら自前ループの Claude Agent SDK か、ホストされるマネージドエージェントか。制御か手軽さかで選ぶ。
- 本番の勘所はデプロイ・監視・コスト・リトライ・状態管理・更新。そして段階リリース・フォールバック・承認ゲート・再評価で崩さない。
- エコシステムは速く動く。4要素・評価・安全という基礎こそが、長く効く資産になる。
全7章、おつかれさまでした。あなたはエージェントを設計し、作り、つなぎ、増やし、測り、守り、運用するまで、ひと通りの道を歩き切りました。ここからは、あなた自身のプロダクトで手を動かす番です。