AIエージェント開発の価値は、
どこに残るのか ── Claude Code時代の「作る／作らない」の線引き

前提──既製のAIエージェントはどこまで来たか

議論の前提として、いまの既製AIエージェントが「どこまでできるようになったか」を押さえておきます。ポイントは次の4つです。

• 1.
  「段取り」をAIが自分で組めるようになった
  以前は「まず計画を立てさせ、実行させ、最後に確認させる」という段取りを、人間が細かくプログラムする必要がありました。いまは「この作業をお願い」と一言伝えるだけで、AIが自分で段取りを組み、間違いに気づけば自分で直します。
• 2.
  仕事に必要な「道具」が最初からそろっている
  ファイルの読み書き、情報検索、システムの操作──AIが作業するための道具一式が、既製品にはじめから組み込まれています。道具を一つずつ用意してつなぎ込む開発は、ほぼ不要になりました。
• 3.
  外部サービスとの連携が「設定するだけ」になった
  SlackやNotionなど普段使うサービスとの接続には、かつてサービスごとに個別の開発が必要でした。現在は「MCP」という共通規格（いわばAI用の共通コンセント）のおかげで、接続先を選んで設定するだけで済みます。
• 4.
  「覚えておく力」も標準装備になった
  社内ルールや過去のやり取りをAIに覚えさせるには、以前は専用の仕組みを自前で開発する必要がありました。いまは指示書のファイルを置いておくだけで、AIが文脈を踏まえて動いてくれます。

もう作らなくていい領域──「作る価値」が薄れた部分

この前提に立つと、次のような開発はすでに既製のAIエージェントで置き換えられるため、自社で作り込む価値はほとんど残っていません。

作業手順を細かくプログラムする開発

かつてのAIは判断力が未熟だったため、「いつ調べるか」「いつ確認するか」を人間が細かく決めて縛る必要がありました。いまのAIは状況を見て自分で判断できます。外側から細かく縛る仕組みは、むしろAIの実力を発揮させない足かせになりがちです。

連携機能や記憶機能の自前開発

「外部サービスとつながる」「過去のことを覚えている」は、もう特別な機能ではなく当たり前の前提になりました。ここに開発費を投じても、既製品の進化に数ヶ月で追い抜かれてしまいます。

社内の定型業務のための専用AI

議事録の作成、問い合わせの一次対応、書類のチェック──こうした定型業務のために専用AIを開発する必要は、ほぼなくなりました。既製のAIに指示書（業務マニュアルのようなもの）を用意するだけで、実用レベルに達してしまうからです。

価値が残る領域──個別開発でしか届かない部分

では、個別開発の価値は消えてしまったのでしょうか。そうではありません。価値は消えたのではなく、より上のレイヤーに移動したのです。具体的には次の5つです。

• 1.
  「間違えてはいけない業務」への作り込み
  医療・法務・金融のように免許や法律が関わる業務では、「なぜその答えになったのか」を説明できること、記録が残ること、一定の正確さを保証することが求められます。既製のAIは「動くこと」は得意でも、「正しさへの責任」までは引き受けてくれません。
• 2.
  お客様が直接触れる画面・体験づくり
  既製のAIエージェントは、あくまで作り手（エンジニア）向けの道具です。お客様が日常的に使うサービスにするには、迷わせない画面設計や、うまくいかなかったときの案内まで含めた体験の作り込みが欠かせません。
• 3.
  サービスとして提供するときの採算設計
  自社サービスにAIを組み込んでお客様に提供する場合、利用が増えるほどAIの利用料もかさみます。用途に応じてAIを使い分け、コストを抑える工夫がサービスの採算を左右します。※ 社内利用が中心であれば、ここはほぼ気にしなくて構いません。
• 4.
  品質を測り、守る仕組み
  「どのくらいの精度で動いているか」「失敗したらどう対処するか」を測定・管理する仕組みは、既製品には含まれていません。業務として安心して任せるには、この品質管理の作り込みが必要です。
• 5.
  自社にしかないデータの活用
  長年蓄積してきた顧客データやノウハウをAIに組み込み、「使われるほど賢くなる」状態を作れれば、それは他社が真似できない強みになります。データの独自性こそ、個別開発に踏み切る最大の理由になりえます。

「作るか、使うか」5つの質問で判断する

最後に、実務でそのまま使える判断軸を5つの質問にまとめます。Yesが多いほど、個別開発を検討する価値があります。すべてNoなら、既製のAIエージェント＋設定の工夫で十分です。

• 免許・法律・監査が関わる業務か

  Yesなら、説明できること・記録が残ることの作り込みが必要＝個別開発の領域です。
• 社外のお客様が直接使うサービスか

  Yesなら、画面や体験の設計が必要です。既製のAIでは届きません。
• 利用が増えるとAIの利用料が利益を圧迫するか

  Yesなら、コストを抑える設計がサービスの採算を決めます。
• 自社にしかないデータが強みの源泉か

  Yesなら、そのデータを活かす仕組みづくり自体が、他社に対する参入障壁になります。
• 失敗したときの損害が大きい業務か

  Yesなら、品質を測り守る仕組みの作り込みが欠かせません。

結論──問いは「作れるか」から「作るべきか」へ

AIエージェント開発の価値は消えたのではなく、求められる場所が変わりました。「動かすための開発」は既製品に任せ、浮いた時間とお金を「信頼性・体験・採算性」というサービスの中身に集中させる──それが、これからの合理的なAI活用戦略だと考えています。

特に、大企業ほどの開発体制を持たない会社こそ、この線引きが重要です。「まず既製品を使い倒し、事業の中核に関わるところだけ作る」。この順番を間違えないことが、限られたリソースで成果を出すいちばんの近道です。