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

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

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

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

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

コードを書く作業だけを切り出せば、AI に任せる範囲がかなり増えていくのは間違いなさそうです。

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

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

ただ、エンジニアがまるごと不要になるとは考えていません。

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

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

以降は、開発支援全般ではなく、業務内の Agent が外部システムを操作する場面を主に扱います。

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

私は主に 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 を投げさせるのは普通に危険です。

• 読み取りだけを許可する
• 用途を絞った Tool を用意し、自由な SQL を直接渡さない
• サーバー側で利用者・対象・操作を認可し、DB 権限も必要最小限にする
• 件数などの条件に応じて、人間の承認を挟む
• Hook で Tool 呼び出しを検査・停止する場合も、安全策を補う位置付けにする

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

Strands の公式資料は、BeforeToolCallEvent で Tool 実行をキャンセルできることを示しています。Hook はこうした検査を実行経路へ加える補助として使えますが、認可や DB 権限の代わりにはなりません。(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 です。

SQLite バックエンドを使う Durable Object では、各インスタンスに紐づくストレージで SQL と point-in-time recovery を利用できます。復元対象はその Durable Object の組み込みデータベースであり、外部システムへの操作は戻りません。(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・業務設計の知識が乗ってくる。

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

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

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

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