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 の得意・不得意も理解していないといけません。

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

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

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

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

追加される領域の関係を、図にすると次のようになります。

図の読み方

1. 下段は、フロントエンド・バックエンド・DB・インフラ・外部連携・監視と運用からなる従来のフルスタックです。
2. その上に、LLM・RAG・Tool Calling・Agent設計というAI Agentの実行領域が加わります。
3. 権限・承認・評価・監査・セキュリティ・コスト・データガバナンスは、特定の一層ではなくシステム全体を横断する責任境界になります。
4. AIがコードを書く範囲を広げても、人間には自動化の範囲と停止条件を設計する役割が残ります。

責任に関わる項目は特定の一層に閉じず、従来のシステムと AI Agent の実行領域を横断します。

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

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

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 などの要素があります。

主な制御部品の役割を整理すると、次のようになります。(AWS ドキュメント)

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

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

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

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

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

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

Strands は Agent の自由度をコードで絞る

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

Strands は Python / TypeScript 向けの Agent SDK として整理されており、Tool・コンテキスト管理・実行制限・可観測性などを扱える構成です。

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

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

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

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

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

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

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

Strands の公式サイトにも、BeforeToolCallEvent を使い、INSERT・UPDATE・DELETE・DROP などの書き込み系 SQL を止める読み取り専用ガードの例があります。(Strands Agents Hooks)

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

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

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

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

Cloudflare は状態を持つ Web Agent の実行基盤

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

Cloudflare Agents は、チャット・音声・メール・Slack・Webhook などを入口に、Browser・Sandbox・AI Search・MCP・Payments などの Tool へつなぐ Agent 実行環境として説明されています。

Cloudflare 上で Agent をホストすると、各 Agent セッションは永続的な識別情報・ローカル SQL ストレージ・リアルタイム接続・スケジュール実行・復旧可能な実行を持つとされています。(Cloudflare Docs)

個人的に面白いと思ったのは、Agent をステートレスな関数ではなく、識別情報と状態を持つ実行単位として扱っている点です。

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

顧客・案件・社内申請ごとに、一つずつ Agent を置く設計も考えられます。

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

こう組み合わせると、Cloudflare は、とくに 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 アプリケーションの入口として、キャッシュ・レート制限・リクエストの再試行・モデルのフォールバックなどを扱えると説明されています。(Cloudflare Docs)

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

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

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

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

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

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

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

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

AI Gateway Guardrails は、ユーザーのプロンプトとモデルの応答の両方を評価し、有害な内容にフラグを付けるかブロックする仕組みとして説明されています。(Cloudflare Docs)

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

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

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

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

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

もう一つは Workflows です。

Cloudflare Workflows は、障害や中断をまたいで継続できる複数ステップ実行を持つものとして説明されています。また、外部イベントや承認を待つための一時停止・自動再試行・エラー処理・可観測性とデバッグ機能もあると説明されています。(Cloudflare Docs)

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

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

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

Cloudflare Workflows の step.waitForEvent API を使うと、実行中の Workflow インスタンスが外部イベントやデータを待てます。人間の承認待ちも、このモデルに乗せやすいと考えられます。(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・業務設計の知識が乗ってくる。

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

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

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

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