1. 「AIエージェントは買うもの」なのか？
前編では、「Claude Code（クロード・コード）で感じる簡単さ」と「企業導入で語られる大変さ」が、同じ言葉で別のレベルの話をしているすれ違いであることを整理しました。
すると、次の疑問が出てきます。AIエージェントとは、特別な製品を買わないと手に入らない「魔法の箱」なのでしょうか。それとも、エンジニアがいれば（あるいはClaude Codeの助けを借りれば）自分たちで作れるものなのでしょうか。
結論を先に書きます。
この2つの文を分けて理解することが、本稿のゴールです。
2. AIエージェントを部品に分解する
AIエージェントは、中身を開けてみれば既存技術の組み合わせです。部品に分解すると、おおよそ次のようになります。
AIエージェント
├─ LLM（判断と文章生成を担うAI本体）
├─ プロンプト（AIへの指示・前提の設計）
├─ 文書検索（RAG：社内文書を検索し、根拠として回答させる仕組み）
├─ システム連携（API：外部システムとの接続口を通じた読み書き）
├─ ワークフロー制御（処理の順番・条件分岐の管理）
├─ 権限管理（誰に・どの操作を許すかの制御）
├─ 記録（ログ：あとから検証するための動作履歴）
├─ エラー処理（失敗時の再試行や復旧）
├─ 人間承認（重要な処理の前に人の確認を挟む関門）
└─ 実行結果の検証（出力が正しいかのチェック）
ご覧のとおり、一つひとつは特別な魔法ではありません。文書検索も、システム連携も、承認フローも、業務システムの世界では昔からある部品です。新しいのは、その中心に「判断と生成を行うLLM」が入ったことだけです。
だからこそ、こう言えます。
- AIエージェントは、製品を買わないと作れないものではない
- 検索回答、要約、分類、ファイル生成、システム呼び出し、一連のワークフロー実行──この範囲はコードで実装できる
- しかも今は、その実装作業自体をClaude Codeがかなり手伝ってくれる
ただし、ここで「だから簡単だ」とは言いません。部品を並べることと、それを業務で安心して動かすことの間には、大きな距離があります。その距離を測るのが次章以降です。
3. Claude Codeで「簡単」に感じる理由
前編で詳しく述べたので要点だけ再掲します。Claude Codeでの作業が簡単に感じられるのは、次の条件が揃っているからです。
- エージェントの実行基盤（ツール呼び出し、結果の受け渡し、危険な操作前の確認）はClaude Code側が用意済み
- 作業対象が主に自分のコードとローカル環境で、失敗しても巻き戻せる
- 人間が横にいて、危ない判断はその場で止められる
Claude Code で作業する
＝ 人間が横にいる前提のエージェント
企業業務を代行する
＝ 人間が常に横にいなくても、壊れず動き続ける必要があるエージェント
この「人間が横にいるかどうか」が、難易度を分ける最大の分岐点です。
4. 難易度は「業務にどこまで触らせるか」で決まる
「AIエージェント開発は大変」と言う人が見ているのは、AIの賢さではありません。社内データベースへの接続、顧客管理システム（CRM）や会計システムとの連携、権限管理、個人情報の扱い、記録の保存、失敗時の巻き戻し、承認フロー、品質評価──つまり、AIを現実の業務にどこまで触らせるかの問題です。
この難易度は、段階表にすると分かりやすくなります。前編で使った「自律度の5段階」が縦の軸だとすれば、こちらは「業務への接触度」という横の軸です。
| 段階 | AIにやらせること | 難易度 | 難しさの中身 |
|---|---|---|---|
| 1 | 文章を作る・要約する | 低い | プロンプト設計くらい |
| 2 | ファイルを読む・書く、コードを直す | 低〜中 | 失敗しても巻き戻せる範囲 |
| 3 | 社内データベースを読む | 中 | 権限・機密情報の扱いが発生 |
| 4 | CRMや会計システムに書き込む | 高い | 誤入力の影響が組織に及ぶ。承認・記録・復旧が必須に |
| 5 | 顧客対応・請求・契約に関わる | かなり高い | 顧客と金銭への直接影響。責任設計が最重要に |
| 6 | 人間の承認なしで実行する | 非常に高い | 事故を防ぐ仕組みをすべて機械側に持たせる必要 |
5. よくある「エージェント事例」をコードに翻訳してみる
世の中でAIエージェントの導入事例として紹介されるものも、冷静に分解すれば、多くは先ほどの部品の組み合わせです。よく見かける3つの類型を、実際に作るとしたらどうなるかに翻訳してみます。
類型1：社内規定に根拠付きで答える検索回答
「社員の質問に、社内規定を検索して根拠付きで答えるAIエージェント」。金融機関や大企業の事例としてよく紹介される型です。作るとしたら、構成はこうなります。
ユーザーの質問
→ 社内文書の検索（RAG）
→ 関連箇所の抽出
→ 回答の生成
→ 根拠となる規定へのリンク提示
この骨格自体は、比較的作りやすい部類です。試作品なら数日で動きます。ただし本番に載せるなら、文書が古くなっていないかの管理、部署ごとに見せてよい文書を分ける権限設計、誤回答をどう検知し訂正するかの仕組みが必要になります。難しいのは検索と回答ではなく、鮮度・権限・誤答対策です。
類型2：通話の要約から顧客管理システムへの自動登録
「コールセンターの通話を要約・分類し、顧客管理システムに自動で登録するAIエージェント」。業務自動化の事例としてよく紹介される型です。
通話音声
→ 文字起こし
→ 用件の分類
→ 要約
→ CRM項目への割り当て
→ 人間の確認
→ CRMへ登録
各ステップは既存技術で実装できます。しかしこの類型で本当に難しいのは、要約そのものではありません。音声認識の誤り、重要事項の要約漏れ、項目への誤った割り当て、登録前の承認、登録後に間違いが見つかったときの修正履歴、そして個人情報の保護。つまり、書き込む先が本番の顧客データであることの重みです。
類型3：コードレビューやドキュメント作成の支援
「コードを解読し、レビューし、修正案とドキュメントを作るAIエージェント」。これはClaude Code利用者が最も実感しやすい型で、実際、個人の開発支援としてはすでに日常です。
ただし、これを組織の開発プロセスに正式に組み込むなら、話が変わります。社内のコーディング規約との整合、テストの自動実行、レビュー責任の所在（AIが見落としたら誰の責任か）、コードを本番に取り込む権限（マージ権限）の設計、セキュリティチェックなどが必要になります。個人で使えば段階2、組織の標準プロセスにすれば段階4以上、という良い例です。
6. 実装は3層で考える
ここまでの話は、3つの層に整理できます。AIエージェントを作るという仕事の全体像です。
| 層 | 含まれるもの | 主な難しさ |
|---|---|---|
| ① AI層 | プロンプト設計、文書検索（RAG）、要約、分類、計画立案 | 精度と出力の安定性 |
| ② 業務連携層 | API連携、データベース接続、ファイル操作、SaaS連携、権限管理 | データ形式の整合、権限、連携先の仕様変更 |
| ③ 運用層 | 記録（ログ）、監査対応、エラー処理、再試行、人間承認、品質評価、セキュリティ | 責任範囲の設計、継続的な運用体制 |
この3層で見ると、ギャップの正体がもう一度はっきりします。
- 多くの人が「AIエージェントを作る」と聞いてイメージするのは①だけ
- Claude Codeで楽に感じるのは①と、②の一部（手元のファイルやGitまで）
- 企業で「大変」と言われているのは②の後半（本番システムへの書き込み）と③のすべて
つまり、AIエージェント開発の難しさの正体は、AI開発ではなく業務システム開発です。①は既製のLLMとツールでどんどん楽になっていますが、②と③は各社の業務そのものなので、外から買ってきて終わりにはできません。
7. 完全自律を目指さない設計が、現実には最も価値を出す
3層モデルの帰結として、設計の指針も明確になります。避けるべきは、次のような発想です。
AIが自分で判断して
AIが自分で実行して
AIが自分で修正して
AIが勝手に完了する
これは先ほどの表の段階6、つまり最も難しい領域から始める発想です。うまくいけば華々しいのですが、③の運用層をすべて完璧に作り込まないと事故につながります。現実的な設計はこうです。
AIが判断材料を集める
AIが下書きを作る
AIが分類する
AIが登録案を作る
── 重要な処理の前に、人間が確認する ──
承認後にシステムへ反映する
記録を残す
失敗したら止まる
8. 内製すべきか、製品を導入すべきか
「コードで作れる」と分かると、次は「では内製すべきか」という問いが来ます。ここは冷静に分けて考える必要があります。コードで作れることと、内製すべきことは別だからです。
内製が向いているケース
- 業務が自社独自で、既製品では形が合わない
- データや権限の設計を細かく制御したい
- 小さく作って業務に合わせて改善し続けたい
- 社内にエンジニアやAI活用人材がいる（Claude Codeのような開発支援があれば、少人数でも現実的です）
製品導入が向いているケース
- 既存のSaaS（クラウド業務サービス）との連携が中心
- とにかく早く始めたい
- セキュリティや運用の作り込みをある程度製品側に任せたい
- 業務が標準的で、既製品の型に合わせられる
- 社内に開発・運用の体制がない
ただし、どちらを選んでも避けられない仕事があります。業務の整理、データの整備、権限の設計、承認フローの設計、利用ルールの策定、効果測定──先ほどの3層モデルでいう②と③の業務側です。
9. まとめ：問うべきは「作れるか」ではなく「どこまで触らせるか」
前後編の内容をまとめます。
- AIエージェントは、LLM・文書検索・システム連携・ワークフロー・記録・承認・検証の組み合わせであり、大部分はコードで実装できる
- Claude Codeを使うと、個人向け・開発支援向けのエージェントはかなり簡単に感じる。それは①AI層と②連携層の手前だけを触っているからである
- 企業業務を任せるには、②の本番システム連携と③の運用層──つまり業務システムとしての設計──が必要になる
- 難しいのはAIに考えさせることではなく、現実の業務に安全に触らせることである
- まずは完全自律ではなく、人間承認つきの半自動化から始めるべきである
AIエージェントは魔法ではありません。コードで作れます。しかし、コードで作れることと、業務を安心して任せられることは違います。本当に問うべきなのは「AIエージェントを作れるか」ではなく、「どの業務を、どこまでAIに触らせてよいのか」です。
その線引きさえ明確になれば、Claude Codeで培った「AIへの仕事の渡し方」は、そのまま企業のエージェント導入にも活きる、確かな土台になります。