AI Agent 時代に、エンジニアは何を設計する人になるのか

最近の AI Agent 基盤や SDK を見ていて、私自身、エンジニアが設計するものが変わってきたように感じています。

よく聞くのは、こんな話です。

AI によってエンジニアは不要になるのか？

私の今の答えは、半分合っていて、半分違うです。

コードを書く作業だけを切り出すと、AI にかなり寄っていくのは間違いなさそうです。

• ちょっとした実装
• 調査
• テストコード
• リファクタリング
• ドキュメント作成
• エラー原因の切り分け

少なくとも私の周りでは、すでに AI を使った方が速い場面が増えています。

ただ、エンジニアがまるごと不要になるかというと、そこは違うのではないでしょうか。

これから中心になるのは、AI を信じるかどうかではなく、AI が間違えても止まる範囲を設計することだと思います。

Agent が見てよいデータ・呼んでよい Tool・止まるべき境界・人間に戻す条件・あとから追えるログ。AgentCore、Strands、Cloudflare の実行基盤を見ながら、そんなことを考えています。

先に観測範囲も書いておきます。

私は主に Web 系の業務システムを開発してきました。低レイヤ・組み込み・研究開発には当てはまらない部分も多いかと思います。あくまで一人のエンジニアが現時点で持っている見立てで、半年後には考えが変わっている可能性もあります。

決定的なシステムに、不確かな判断主体が入ってくる

これまで私が関わってきたアプリケーション開発では、入力・処理・出力をできるだけ決定的にするのが基本でした。

API は決められたリクエストを受け取り、バリデーションを通してレスポンスを返す。バッチは決まった時間にデータを決まった形式へ変換する。フロントエンドはユーザー操作に応じて、想定した UI 状態を返します。

もちろん、現場はそんなにきれいではありません。

• 外部 API が落ちる
• DB が詰まる
• ユーザーが想定外の操作をする
• 要件が途中で変わる

分散システムのように、もともと非決定性と向き合ってきた領域があることも承知しています。

それでも、少なくとも私が関わってきたアプリケーション開発は、フロントエンド・バックエンド・インフラ・ミドルウェア・監視・テストまで、だいたい「入力・処理・出力を決定的に近づける」という考え方の上にありました。

AI Agent は、この前提を少し変えます。

ユーザーの依頼は曖昧で、言葉も前提も揺れます。本人が何を頼みたいのか整理できていないことさえあります。

LLM はその入力を解釈し、推論し、文章を生成します。似た入力であっても、毎回まったく同じ出力が返るとは限りません。

文章を返すだけなら、まだ人間が読んで判断できます。

ただ、Agent が Tool を呼び、外部 API や DB に触れ、ワークフローを進めるところまで来ると、出力はただの文章ではなく、業務への作用になります。

AI を信じるのではなく、間違えても止まるようにする

AI Agent を「賢いチャットボット」くらいに捉えてしまうのは、かなり危ないと思っています。

たとえば、次のような操作です。

• 顧客情報を見る
• チケットを更新する
• 請求書を処理する
• 社内システムへ登録する
• メールを送る
• 外部 API を叩く
• 申請を進める

Agent がここまで担うようになると、間違いは回答品質の問題では済みません。

AI は文脈を読み違えます。もっともらしい嘘を出すことも、意図しない Tool を呼ぶこともあります。プロンプトインジェクションもあり、権限を渡しすぎれば普通に危険です。

LLM の挙動を、if 文や switch 文のようにすべて書き切るのは無理があります。

だからこそ、先に決めておきたいのが次の境界です。

• 参照してよいデータはどこまでか
• 呼び出してよい Tool は何か
• 実行してよい操作はどこまでか
• 認証・認可をどう分けるか
• どこから人間の承認が必要か
• 失敗時にどう止めるか
• どのログを残し、あとから監査できるようにするか
• コストの暴走をどう検知するか
• 出力品質をどう評価するか

ざっくり図にすると、次のような構造になるかと思います。

こうして見ると、プロンプトより外側の話がかなり多いです。

普通にシステム設計の話ですよね。

Agent が業務を進めるほど、境界線が効いてくる

業務で本当に価値が出るのは、Agent が文章を返した後だと思います。

問い合わせ対応であれば、顧客情報・過去の対応履歴・注文情報を確認し、返金可否を判断する。必要であれば担当者へエスカレーションし、対応内容を記録します。

経理であれば、請求書を読み、発注情報と照合し、金額や支払条件を確認する。不一致なら止め、問題がなければ承認フローを経て会計システムへ登録します。

ここで怖いのは、Agent がそれっぽく判断できることです。

それっぽく見えるからこそ、どこまで任せるのかは慎重に決めないといけません。

個人的には、次のような作業は AI に寄せやすいと思っています。

• 調査
• 要約
• 下書き
• 照合
• 候補出し

反対に、次のような操作には強い境界が必要です。

• 確定
• 送金
• 削除
• 契約
• 対外的な意思決定

この線を引かないまま「AI Agent で自動化できます」と言うのは、かなり危ないです。

PoC では動くし、デモも映えるかと思います。 ただ、本番業務へ入れた途端、権限・ログ・監査・例外処理・責任の問題が一気に表へ出ます。

ここを避けてしまうと、デモの先には進めない気がしています。

実装スピードだけを価値にするのは厳しくなる

ここは私自身への戒めでもあります。

エンジニアが消えるというより、コードを書くスピードだけを価値の中心に置く戦い方が厳しくなっていくのだと思います。

もちろん、実装力に価値がなくなるという話ではありません。

高難度な領域のスペシャリスト・パフォーマンスチューニング・低レイヤ・複雑なドメインの実装では、深い実装力そのものが引き続き価値になります。

ただ、私がいる Web 系の業務システム開発では、次のような作業は AI の支援でかなり速くなっています。

• ちょっとした API の実装
• バリデーション
• テストコード
• 型定義
• リファクタリング
• ドキュメント
• ログ調査
• エラー原因の当たりをつける作業

コードを書けなくてよいわけでもありません。

Agent が実行する Tool は誰かが実装します。外部 API との接続・認証・認可・ログ・インフラにも、コードとシステムへの理解が要ります。

AI の出力を評価するには、むしろ今まで以上にコードを読めないと困るのではないでしょうか。

そのうえで問われるのが、何を、どこまで自動化してよいかです。

ここを設計できなければ、実装効率化の恩恵を受ける側ではなく、置き換えられる側に回りやすくなる。私はそんな危機感を持っています。

フルスタックの上に、AI の責任範囲が乗ってくる

Agent を業務へ入れるには、フロントエンド・バックエンド・インフラ・DB・認証・認可・外部システム連携・ログ・監視・セキュリティ・業務フローまで、ある程度横断して見られる必要があります。

もちろん、AI の得意・不得意も理解していないといけません。

LLM API を一度呼べば終わりではなく、業務を分解し、Agent に渡す単位を決め、Tool を設計し、権限を絞る。データの鮮度を見て、出力を評価し、人間に戻すラインを決める。監査ログを残し、本番で運用する。

そこまで含めて、ようやく業務システムとして使える形になるのかなと思います。

従来のフルスタックが、フロントエンド・バックエンド・インフラ・DB・外部 API 連携・監視・運用を横断する役割だとすれば、今後はさらに次の領域が加わります。

• LLM
• RAG
• Tool Calling
• Agent 設計
• Evals
• プロンプトインジェクション対策
• データガバナンス
• Human in the loop
• 監査ログ
• コスト管理
• 会社として AI を使うときの責任範囲

正直、普通に大変です…。

すべてを一人で完璧に持つのは現実的ではなく、実際にはチームで分担することになるかと思います。それでも、全体像を把握して境界を設計できる人は、どのチームにも必要になるはずです。

AI がコードを書いてくれる分、実装の一部は楽になります。その代わり、設計と責任の範囲は広がる。

こちらの見方の方が、私にはしっくりきます。

AgentCore は、本番業務のための実行環境と制御部品

AWS 側では、Amazon Bedrock AgentCore をこの文脈に近いものとして見ています。

AgentCore は、任意のフレームワーク・基盤モデル・プロトコルと組み合わせて Agent を動かすための基盤として説明されています。

Runtime は CrewAI・LangGraph・LlamaIndex・OpenAI Agents SDK・Strands Agents などのフレームワーク、Amazon Bedrock 内外のモデル、MCP / A2A などのプロトコルと連携できるとされています。(AWS ドキュメント)

「Agent を作りやすくするサービス」という見方もできます。

ただ、私が注目しているのは、その後ろにある実行環境と制御部品です。

Agent を作る方法は、すでにいくつもあります。

本番で困るのは、誰の権限で実行するのか・どの Tool を呼ばせるのか・何のデータを見せるのか・どこで人間に戻すのか・どうログと評価を残すのか・コストの暴走をどう止めるのか、という部分です。

AgentCore には、Memory・Gateway・Identity・Code Interpreter・Browser・Observability・Evaluations・Optimization・Policy・Registry などの要素があります。

Gateway は既存 API や Lambda などを MCP 互換の Tool にする仕組み、Identity は Agent の認証・認可、Observability は Agent の実行経路や中間出力を追う仕組み、Evaluations は Agent と Tool の実行品質を評価する仕組み、Policy は Agent がどの Tool をどの条件で実行できるかを定義する仕組みとして整理されています。(AWS ドキュメント)

Runtime・Memory・Gateway・Identity・Observability・Evaluation・Policy。

この並びを見ると、Agent を本番運用するときに問題になる部分が、そのまま出てきているように感じます。

• 誰の権限で実行されたのか
• なぜその Tool を呼んだのか
• どのデータを見たのか
• なぜ人間に確認せず進めたのか
• 失敗時にどこまで戻せるのか
• 後から追えるログが残っているのか

このあたりが分からない Agent は、業務ではかなり使いづらいと思います。

なお、私はまだ AgentCore の全コンポーネントを本番で使い込んだわけではありません。

ここで書いているのは、ドキュメントと発表を見て、方向性に納得している段階の話です。実際に使い込んだ知見は、また別の記事で書きたいと思っています。

Strands では、Agent の自由度をどこで絞るかを見る

AgentCore が実行基盤寄りだとすれば、Strands は Agent を実装する SDK です。

Strands は Python / TypeScript 向けの Agent SDK として整理されており、Tool・context management・execution limits・observability などを扱える構成です。

公式サイトでは、Python と TypeScript の両方で Tool を定義して Agent に渡す例が示されています。(Strands Agents)

ここも「数行で Agent が作れる」ことより、Tool の前後へ処理を差し込み、危ない操作を止め、ログやトレースを残せる点に注目しています。モデルや実行基盤を差し替えやすいことも含まれます。

Strands の Hooks は、Agent のライフサイクル中のイベントへ処理を差し込む仕組みです。

BeforeInvocationEvent・BeforeToolCallEvent・AfterToolCallEvent などに callback を登録でき、Tool 実行前のキャンセル・Tool の差し替え・Tool 入力や結果の書き換えも扱えると説明されています。(Strands Agents Hooks)

たとえば、Agent に DB を触らせるとしても、自由に SQL を投げさせるのは普通に危険です。

• 読み取りだけを許可する
• UPDATE / DELETE / DROP は止める
• WHERE 句がなければ実行しない
• 一定件数以上を操作するときは人間に確認する
• 外部 API を呼ぶ前に権限を確かめる

このあたりまで実装できて、初めて Agent を業務へ近づけられるのかなと思います。

Strands の公式サイトにも、BeforeToolCallEvent を使い、INSERT・UPDATE・DELETE・DROP などの書き込み系 SQL を止める read-only guard の例があります。(Strands Agents Hooks)

Strands のような SDK は、Agent を簡単に作るためだけのものではありません。

Agent の自由度をどこで絞るかを書くための道具でもある。

私は、そのように見ています。

プロンプトの外側を Tool・hook・policy・権限・監査ログで囲う。ここを仕組みとして設計できるかどうかが、本番投入の分かれ目になると思います。

Cloudflare は、状態を持つ Web 寄りの Agent 基盤

Cloudflare 側にも、Agent を動かすための部品が揃ってきています。

Cloudflare Agents は、chat・voice・email・Slack・webhook などを入口に、Browser・Sandbox・AI Search・MCP・Payments などの Tool へつなぐ Agent 実行環境として説明されています。

Cloudflare 上で Agent をホストすると、各 Agent session は durable identity・local SQL storage・real-time connections・scheduled work・recoverable execution を持つとされています。(Cloudflare Docs)

個人的に面白いと思ったのは、Agent を stateless な関数ではなく、identity と state を持った実行単位として扱っている点です。

Agent ごとに状態を持ち、必要なときに起き、使っていないときは寝る。WebSocket・メール・Slack・Webhook から起動して Tool を呼び、長い処理や承認待ちは Workflows に渡す。

顧客・案件・社内申請ごとに Agent 的な単位を置く設計も考えられます。

LLM 呼び出しは AI Gateway で観測し、社内文書やナレッジの検索は AI Search や Vectorize のような検索基盤へ寄せる。

こう組み合わせると、Cloudflare は軽量な Agent アプリケーション、とくに Web アプリケーション寄りの Agent を作る選択肢になりそうです。

フロントエンドや Web アプリケーション寄りの開発者であれば、Workers・Durable Objects・Agents SDK・Workflows・AI Gateway で小さく試しやすいのではないでしょうか。

Cloudflare Agents の土台は Durable Objects です。

Durable Object Storage API では、各 Durable Object のストレージは一意なインスタンスに紐づき、SQL や point-in-time recovery などを使えると説明されています。(Cloudflare Docs)

Agent ごとの状態・会話履歴・処理途中の状態・リトライ用の情報を持たせる設計とは、相性がよさそうです。

ただし、Cloudflare を使えば安全になるわけではありません。

• 状態をどこまで持たせるか
• どのイベントで起動するか
• どの Tool を呼ばせるか
• LLM 呼び出しをどう観測するか
• レート制限をどう入れるか
• 人間の承認をどこに挟むか
• 業務データへのアクセス権限をどう切るか
• ログをどう残すか
• コストの暴走をどう止めるか

このあたりは、こちらで設計する必要があります。

AWS でも Cloudflare でも、Agent を作っただけでは足りない点は同じです。

AI Gateway は、LLM 呼び出しを観測して止める

Cloudflare の部品で特に実務寄りに見ているのが、AI Gateway と Workflows です。

AI Gateway は、AI アプリケーションの入口として、caching・rate limiting・request retry・model fallback などを扱えると説明されています。(Cloudflare Docs)

LLM 呼び出しは、放っておくと見えづらいです。

• 誰がどれだけ使っているのか
• どのモデルを呼んでいるのか
• トークンをどれだけ使っているのか
• エラーがどれだけ出ているのか
• どこで遅くなっているのか
• コストがどこで膨らんでいるのか

ここが見えないままでは、業務システムへ入れにくいと思います。

Cloudflare AI Gateway の rate limiting は、AI Gateway へのトラフィックを制御し、高額な請求や不審なアクティビティを防ぐ機能として説明されています。(Cloudflare Docs)

spend limits では、コストベースの予算を設定し、一定期間内の累積コストが上限に達するとリクエストをブロックできるとされています。(Cloudflare Docs)

Agent はループするかもしれません。Tool 呼び出しに失敗して再試行し、想定より多くモデルを呼ぶ可能性もあります。

「気づいたらコストが跳ねていた」は、普通に起こり得ます。

アプリケーション側だけではなく、Gateway 側でも止められるようにしておくと、だいぶ安心できるのかなと思います。

AI Gateway Guardrails は、ユーザーの prompt とモデルの response の両方を評価し、有害な内容を flag / block する仕組みとして説明されています。(Cloudflare Docs)

もちろん、Guardrails を入れればすべて安全という話ではありません。

それでも、入力をそのままモデルへ渡してよいのか。出力をそのままユーザーや業務システムへ渡してよいのか。

この二つは確認しておきたいです。

(これをプロンプトだけで頑張るのは、さすがに無理があります…)

Workflows は、長い処理と承認待ちを引き受ける

もう一つは Workflows です。

Cloudflare Workflows は、durable multi-step execution・外部イベントや承認待ちの pause・自動 retry・error handling・observability / debugging を持つものとして説明されています。(Cloudflare Docs)

Agent は、ユーザーや外部イベントとやり取りしながら判断して、Tool を呼ぶ。

Workflows は、長い処理・確実に実行したい処理・承認待ち・リトライを引き受ける。

この分け方は、実務でもかなり使いやすそうです。

Cloudflare Workflows の step.waitForEvent API を使うと、実行中の Workflow instance が外部イベントやデータを待てます。人間の承認待ちも、このモデルに乗せやすいと考えられます。(Cloudflare Docs)

たとえば請求書処理であれば、Agent が内容を読み、発注情報と照合し、問題がなければ Workflows に渡す。

Workflows 側では、承認待ち・会計システムへの登録・通知・失敗時のリトライを扱う。

Agent に長い業務フローをすべて背負わせるより、こちらの方が現実的な気がしています。

三つの基盤から見えるのは、プロンプトの外側

AgentCore・Strands・Cloudflare Agents は、どれも「Agent を簡単に作る道具」と見ることができます。

もちろん、作りやすさは普及に欠かせません。

ただ、私にはそれ以上に、本番業務で必要になる次の要素を扱うための道具に見えます。

• 実行環境
• 状態管理
• Tool 接続
• 権限
• 監視
• 評価
• 人間の承認
• コスト制御
• ポリシー適用

Agent に何をさせて、何をさせないのか。どこで止めて、どこから人間へ戻すのか。失敗時に何が残るのか。どの基盤に何を担当させるのか。

AI Agent のエンジニアリングは、プロンプトの外側にあります。

ここを決めずに「Agent を作った」と言っても、本番ではすぐに詰まるだろう、というのが私の予想です。

ホワイトカラー業務は、操作ではなく境界から再設計される

これまでの業務システムは、人間がログインし、画面を見て、検索・入力・確認・申請・承認をする前提でした。SaaS の UI も、基本的には人間向けです。

Agent が業務を進めるようになると、人間がすべての画面操作を担う必要はなくなります。

Agent は裏側で API や Tool を使い、人間は重要な判断や承認だけを見る。この形へ寄れば、ホワイトカラー業務はかなり再設計されるはずです。

ただし、全部が自動化されるとまでは思っていません。

自動化へ寄せやすいと感じるのは、次のような作業です。

• 調査
• 要約
• 照合
• 起票
• 下書き
• 分類
• レポート作成
• 一次回答
• 定型的な更新処理

一方で、次のような部分は、そんなに簡単には消えないと思います。

• 最終判断
• 例外対応
• 顧客との信頼関係
• 契約上の責任
• 会社としての意思決定
• 倫理的にグレーな判断

仕事が消えるというより、人間がやる作業と Agent に任せる作業の境界線が引き直される。

そして、その線を実装するところに、エンジニアの新しい仕事があるのではないでしょうか。

まとめ：エンジニアの定義が変わる

決まりきった仕様を、決まりきったコードへ落とすだけの仕事は減っていく。実装スピードだけを価値の中心に置く戦い方も、少しずつ厳しくなると思います。

その一方で、AI Agent を業務システムの中で安全に動かすには、まだ多くのエンジニアリングが必要です。

• Tool を作るためのコード
• 本番で動かすためのインフラ
• 業務データとつなぐためのデータ設計
• 外部システムを操作するための認証・認可
• 誤動作を見つけるための評価と監査
• 事故を抑えるためのセキュリティ
• 会社として使うための責任範囲

実際に業務へ入れる前には、最低でも次の項目を確認しておきたいです。

エンジニアは消えるのではなく、エンジニアの定義が変わる。

これから需要が増えるのは、不確かな AI を業務で使える形に閉じ込める人ではないかと思います。

最近の Agent 基盤や SDK を追うほど、その感覚が強くなっています。

今までのフルスタックに、AI Agent・セキュリティ・責任ある AI・業務設計の知識が乗ってくる。

正直、楽な未来ではありません。

ただ、きちんと取りにいけば、ホワイトカラー領域をシステム化する新しい仕事はかなり増えると思います。

これは、あくまで私の観測範囲から見た現時点の意見です。「うちの現場では違う」「この見立ては甘い」という視点もあるはずです。

半年後に読み返して、どこまで合っていたか答え合わせをしたいと思います。