OpenAI が能力向上と自社エージェントの逸脱を同時に公開、各サービスはエージェントの制御手段に集中

Ubuntu マシン 1 台にダッシュボードとリバースプロキシを載せ、コンテナ化したアプリを並べる構成。Imbue のマネージド版を併設し、収益モデルを明示している。

コメントでは「クラウド以前は各自がホストしていた」という前提に対し、当時のソフトに現代 SaaS の信頼性や堅牢性はなかったとして美化だという批判が上位に来た。一方、サブスクと個人データの預け先から離れたい需要は強く、現状この領域が docker compose 前提で敷居が高いという指摘も並ぶ。

単一マシン構成にはフェイルオーバーがなく、クラウドの利点である冗長性が欠けるという指摘、マネージド版のページにバックアップへの言及が見当たらないという確認もあった。セルフホスティングを勧めながら全体を Claude で作っている点を奇妙だとする声も出ている。

書き手ではなく読者の側の変化を扱った記事で、判定サービス Pangram とその共同創業者への言及がある。Lobsters でも同日首位に入った。

コメントでは、HN の投稿に Pangram の判定を表示するブラウザ拡張が欲しいという要望、「書く価値がないものは読む価値もない」という同意が並んだ。職場で仕様書や設計提案をボットに書かせる例が挙がり、それが強い忌避感を生んでいるという報告もある。

一方、Pangram への言及は相互宣伝ではないかという指摘、AI 文章に気づかなかった人はそもそも気づけないため検出率は測りにくいという反論、人間の文章が AI 判定された事例への言及も出ている。

周波数比から音律を組み立てる形で、音階と和音の成り立ちを段階的に説明する構成になっている。

コメントでは、理解できなかった題材が平易になったという評価、「オクターブも五度も純正で閉じる体系は存在せず、どの調律も誤差の置き場所の選択にすぎない」という一節への同意が並んだ。

一方、音感が弱い読者には冒頭のオクターブの説明が届かないという指摘、18 日間で同じ記事が 4 回投稿されている点への疑問、音楽の複雑さを単純化しすぎだという批判もあった。

Ken Thompson の「Reflections on Trusting Trust」を、コンパイラではなく実行ファイルを加工する strip を足がかりに再現した論文。

コメントでは、Thompson の攻撃は思考実験だと理解していたが実際に構築されたことへの驚き、Thompson 自身が当時実装していたという記録へのリンクが挙がった。Russ Cox が本人からコードを受け取り、ブラウザ上で再現できる形にした資料も紹介されている。

ld や ld-linux.so も同様に狙えるという指摘、Guix と Nixpkgs が hex0 由来のブートストラップ連鎖を使っているという確認、BFD や Gold がどこまで影響を受けるかは不明だが再現可能ビルドの動機が強まるという見立てが並んだ。

NAS とバックアップにどのファイルシステムを使い、なぜそれを選んだかを尋ねる Ask スレッド。

回答はほぼ ZFS で、FreeBSD 上でミラーストライプや RAID-Z を組む構成が並んだ。rsync の代わりに zfs のスナップショット送信で暗号化したまま遠隔複製できる点、zrepl による自動化が利点として挙げられている。

暗号化されていないローカルのデータセットを、鍵を手元に残したまま暗号化された遠隔側へ送ることはネイティブ ZFS ではできないという確認、LUKS や iSCSI・GELI と組み合わせる回避策、zfs.rent のような預け先サービスの紹介と米国外の同種サービスを探す声もあった。

スキーマを前もって定義せず、どの関数を呼ぶかでパースの挙動が決まる設計の Zig 向け引数パーサ。

未知のオプションをエラーにする方法が見当たらないという質問、短縮オプションの構文が POSIX の慣行（`-f arg` と `-farg`）に従っていないという指摘が寄せられた。作者はスレッド内で `unknownOptions()` を実装し、コミットへのリンクを返している。

TigerBeetle の tagged union を使った宣言的なパーサが対比として挙がり、作者はスキーマ先行の方式が優れる用途は多いとしつつ、zopt は別のニッチを狙っていると応じた。

劣化したコードベースをどう扱うかを論じた記事で、Amazon のような大企業が取れる選択肢として、新しい用途に必要な最小限の機能だけを持つ独立したシステムを別チームで作る「サイドチャネル」が挙げられている。

コメントでは、理解していない業務ロジックを「作り直せば明確になる」と考える発想への疑問が上位に来た。作り直すにはまず理解が必要で、再設計は高度に見えるだけだという指摘である。一方、レガシーはノイズが多いため、コードベースの読解が理解への最短路とは限らないという反論も付いた。

全面書き直しが成功しにくい理由として、旧システムが本番を支え続けるため要件が動き続ける点が挙がった。既に把握できた部分から順に置き換える段階的な方式のほうが事業上も妥当だという意見が並んでいる。

モナドの解説を平易な調子で書いた README を、作者自身が投稿したもの。

上位コメントは用語の使い方が一貫していないという批判で、「モナドは実体をラッパーに入れる方法を持つ」という記述が定義なのか性質なのか判別できないと指摘した。作者は一部は妥当な指摘として文言を締める意向を示しつつ、配列も IEnumerable<T> もモナドだと反論している。

別のコメントは、List・Option・Promise に共通する点から入る説明順のほうがプログラマには伝わりやすいという自身の教え方を紹介した。技術編集者を勧める書き込みもある。

AI エージェントに過剰実装をやめさせるスキル。ベンチマークは headless の Claude Code セッションで fastapi/full-stack-fastapi-template を実際に編集させ、残った git diff を採点する形で取られている。

12 件の機能チケット、Haiku 4.5、n=4 での平均は、スキルなしと比べて LOC -54%、トークン -22%、コスト -20%、時間 -27%、安全性は 100% を維持。比較対象の「YAGNI + 一行で書け」プロンプトは LOC -33% だが安全性が 95% に落ち、簡潔な文体だけを与えた対照群は LOC -20% でトークンはむしろ増えた。

削減幅は過剰実装の余地に依存し、日付ピッカーでは 404 行から 23 行（94% 減）、既に最小限のコードではほぼゼロと明記されている。以前の単発ベンチマークが示した 80-94% は平均ではなくタスクごとの上限だと訂正されている。

Claude Code、Codex、Opencode、Cursor など複数のエージェントハーネスにまたがって、スキル・instincts・メモリ・セキュリティ・調査先行の開発フローを提供するパッケージ。

README は警告から始まり、公式の配布経路を GitHub リポジトリ、npm の `ecc-universal` と `ecc-agentshield`、GitHub App、プラグイン slug `ecc@ecc`、公式サイトに限定している。第三者による再アップロードや非公式ミラーは保守もレビューもされておらずマルウェアを含む可能性がある、と明示している。

導入は `npx ecc-universal setup` によるガイド付きセットアップか、Claude Code のネイティブなプラグインコマンドのいずれかで、両方を重ねないよう繰り返し注意している。Node.js 18 以降、Git、Claude Code 2.1 以降が前提。OSS 部分は MIT で無償、私有リポジトリ向けの ECC Pro が資金源という構成。

AI が生成した文章を、意味を変えずに人が書いたように読める形へ書き直すスキル。Markdown だけで構成されているため、スキルに対応するエージェントであれば動く。

自分の文体に寄せたい場合は、自分の文章を 2〜3 段落貼り付けると、リズム・語選び・句読点・意図的な癖まで踏襲する。ファイルパスを渡せばその中の散文を書き直す。

設計の前提として、言語モデルは次に来る確率が最も高いものを書くため、読者と主題を広く取った既定の選択に寄ると説明している。検出対象の兆候はすべてこの既定の選択の一形態として整理されており、事実を足さずに重要性だけを示す文、規則的に適用されたリズムや書式、平凡な事実を決定的なものとして飾る記述などが挙げられている。

エディトリアル品質の作図を目的としたスキルで、39 種類の図版タイプを持つ。出力は自己完結した HTML + SVG で、影を使わず Mermaid も使わない方針を掲げている。

2.5.10 で Sankey、特性要因図、Wardley マップ、カンバン、ユーザージャーニー、デプロイ図、依存グラフ、UML クラス図、ストーリーマップ、データベーススキーマの 10 種が追加された。2.3 では意味論的なシステムパターンと任意のモーションが加わり、静的出力は既定のまま維持されている。

draw.io や Mermaid のソースを、指定した形式・サイズ・詳細度で描き直す機能も持つ。作者は、図が必要になるたびに汎用的な角丸ボックスが返ってきて Figma と 30 分格闘するか作図自体を諦めていた、という動機を挙げている。

マシンをプロファイリングして適合するローカルモデルを推薦し、ダウンロードとチューニングと実行までを担うオープンソースの推論サーバ。Pi、OpenCode、Hermes、OpenClaw、Codex、Claude Code、Cline などから利用でき、内蔵のハーネスもある。

導入はエージェントに指示文を渡す方式と、`npm i -g @magnitudedev/cli` の後に `magnitude setup` を実行する方式の 2 通り。対話的なセットアップがチップ・メモリ・帯域を測り、推定 tok/s 付きで候補を提示する。

投機的デコーディングや並行度がマシンに合わせて設定され、モデルは要求時に読み込まれ、アイドル時やメモリ逼迫時に解放される。トークン課金・API キー・レート制限が不要で、モデルとプロンプトとファイルは手元に留まる点を利点に挙げている。macOS と Linux に対応し、Windows は WSL 経由。ライセンスは Apache 2.0。

オープンソースの AI コーディングエージェントで、README は 20 以上の言語に翻訳されている。

導入経路が多く、インストールスクリプト、npm / bun / pnpm / yarn、scoop、choco、Homebrew（公式 formula と tap の両方）、pacman、AUR、mise、nix run が並ぶ。0.1.x より古い版は削除してから入れるよう注意書きがある。

デスクトップアプリはベータで、macOS（Apple Silicon / Intel）、Windows、Linux（.deb / .rpm / .AppImage）向けに配布されている。インストール先は `$OPENCODE_INSTALL_DIR`、`$XDG_BIN_DIR`、`$HOME/bin`、`$HOME/.opencode/bin` の優先順で決まる。

Nous Research が公開したエージェントで、学習ループを内蔵している点を特徴に挙げている。複雑なタスクの後に自律的にスキルを作り、使用中にそのスキルを改善し、知識の保存を自分で促し、過去の会話を検索する。

動作環境は 5 ドルの VPS から GPU クラスタ、アイドル時にほぼ課金されないサーバーレスまで。ターミナル、Telegram、Discord、Slack、WhatsApp、Signal を単一のゲートウェイプロセスから扱い、音声メモの文字起こしとプラットフォームをまたぐ会話の継続に対応する。

モデルは Nous Portal、OpenRouter、OpenAI、自前エンドポイントなどから `hermes model` で切り替える。cron スケジューラ、サブエージェントの並列実行、ローカル・Docker・SSH・Singularity・Modal・Daytona・Vercel Sandbox の 7 種類のターミナルバックエンドを持つ。

HumanLayer による Claude Code 向けスキル集で、`npx skills add humanlayer/skills --skill SKILLNAME` の形で個別に導入する。

収録は 5 件。improve-claude-md は CLAUDE.md をブロック構造で書き直して指示の遵守率を上げる。narrow-react-prop-types は React コンポーネントの prop 型を、Storybook やテスト、モックでしか通らない状態ではなく実際のコードパスに合わせて絞り込む。

残りは、リポジトリ内スキルと反復型のコーディングエージェント用 GitHub Actions ワークフローを組み立てる build-iterated-agentic-loop、センサー・コントローラー・アクチュエータ・外乱を聞き取って制御ループを設計する design-control-loop、図とコードの骨格と HTML アーティファクトで説明する show-me。

登録不要でブラウザから即座に使えるオープンソースツールを集めたカタログサイト。NoSignups に改名している。

実装は React + TypeScript で、clone して `npm install` と `npm run dev` を叩けばローカルで動く。掲載ツールは id・name・description・url・category を必須、tags・github・license・stars・featured・notRecommendedReason を任意とするスキーマで管理される。

カテゴリは all・productivity・design・development などが既定で用意されている。強制的な登録の壁、データの収集と追跡、プロプライエタリなブラックボックス、不要な肥大化を拒否する立場を表で示している。

半年前の設定記事の続編で、現時点の環境のスナップショットとして書かれている。settings.json は `advisorModel` に fable、`permissions.defaultMode` を `auto`、`viewMode` を `focus` にする構成。細かいコード確認をしない前提で、主要なやり取りだけを表示させている。

入力周りでは 8bitdo micro をターミナルコントローラーとしてマッピングし、片手で操作している。`y` を単体で割り当てているのは、`y` の送信が承諾を意味するため。音声入力は速度ではなく身体的な負担の軽減が目的だと書かれている。

運用面では、エージェントが稼働している間だけスリープを抑止する仕組み、SD スロットに挿す SidePulse で作業中は緑、完了時は明るく、対応が必要なときはオレンジに光らせる通知、settings.json の差分を正規化する処理を用意している。

Claude Code がコードの全体像を持たず、毎回ファイルを読んで関係を推測している点を出発点に、構造をナレッジグラフとして渡す構成を紹介している。使うのは code-review-graph / better-code-review-graph、Graphify、Serena の 4 つの OSS。

TypeScript のタスク管理 API での実測では、pre-commit フックが供給するレビュー用コンテキストが全文読みで 9,272〜142,188 トークンだったのに対し、グラフ経由では 6 コミット連続で約 70 トークンに収まった。

意味検索では「トークンを検証する処理」という日本語の問い合わせに `verifyToken` が類似度 0.52 で 1 位に返り、影響範囲の分析では認証まわり 4 ファイル（17 ノード）の変更が 2 段先で 22 ノード、追加 8 ファイルに波及することを示した。`getConnection()` にエッジが 11 本集中している構造も可視化されている。

長時間稼働するエージェントの精度低下に対し、会話履歴を入力せず「現在の実行状態（State）」だけを渡す手法の解説。Google と Purdue 大学の研究者が 2026 年 8 月に提案した論文（arXiv:2608.26263）をまとめている。

事前に業務ごとの状態のスキーマを定義しておき、毎ターン LLM に渡すのは固定のスキル指示・現在の構造化された State・最新の観測結果の 3 つだけ。LLM は思考プロセスと次のアクション、そして State への JSON パッチを出力し、パッチだけを適用して思考プロセスは破棄する。

SkillExecBench、InterCode CTF、Sierra τ-Bench のいずれでも既存手法を上回り、InterCode CTF では最強のベースラインから +7.8 ポイント。定型業務向けであり、事前に手順を定義できないイレギュラー業務には向かないと明記されている。

社内で HTML を共有するサービスの認証を Google Workspace に集約した設計の記録。インフラは AWS（CloudFront + Lambda + S3 + DynamoDB）で、認証だけを Google に借りている。設計と疎通確認まで終えた段階で、本番投入はこれから。

使う仕組みは 4 つ。人のログインは Google OIDC と OAuth 同意画面の「内部」タイプで、後者により組織外のアカウントはアプリに到達しない。アプリ側でも hd クレームを二重に確認し、ID トークンは JWKS で署名検証する。

在籍確認に使う Directory API には、鍵を持たずに GCP を呼ぶ Workload Identity Federation と、管理者として振る舞うためのドメイン全体の委任の 2 段が要る。CI 用トークンを在籍チェックの対象にすると発行者の退職時に CI が壊れるため、人・機械・CI で認証を分けている。

読者のレベルを極端に下げる指示が、モデルに要約ではなく構造の抽出を強制する、という気づきから始まる記事。きっかけは「5 才児でもわかる絵本風に」という依頼で、モデルのリリースノートを読むより早く差分が掴めたことだった。

題材は、人事情報の変更からアカウント作成や権限剥奪のタスクを生成する 2,000 行超のクラス。割当種別ごとの分岐、前倒し・後ろ倒し、アカウント削除日の調整、グループプッシュ用の別系統、メモリ対策のストリーミング化が重なっている。

Claude Code は呼び出し元と呼び出し先を辿り、仕様書のディレクトリも参照したうえで 1 枚の HTML を出力した。前回生成時点を「しおり」、スナップショットを「写真」、既存タスクとの打ち消しを「反対の付箋を剥がす」と表現し、インライン SVG の図解 6 点と、たとえとクラス名・メソッド名の対応表を付けている。

Artifact Share の CLI に追加した preview コマンドの実装記録。ブラウザ上でファイルの要素をクリックして指摘を書くと、Claude Code・Codex・Cursor がファイルを直し、ブラウザが自動リロードで結果を見せる。

核になった設計判断は 2 つ。エージェントを起こす合図は 3 つのエージェントで別々に作る必要があり、常駐デーモンは不要で 1 ファイル 1 プロセスで足りた。Claude Code はバックグラウンドタスク完了時の自動ターン再開、Codex は実行中セッションへのメッセージのキュー投入、Cursor は ACP で常駐させた専用セッションへの固定プロンプト送信を使っている。

共通の保険として待機コマンドをフォアグラウンドで実行する方式も残しているが、その場合はターンが塞がる。エージェントの 1 周は `preview next --wait` で指摘を受け取り、編集後に `preview done --stdin` で報告する形。

Claude Code が書くコメントを減らす試みの計測記録。マージした PR の diff で、追加行のうち `//` で始まるものをコメントとして比率を出している。

ルールとして書いた場合のコメント比率の中央値は、ルールなし 18.5%、`.claude/rules/` に表形式 21.0%、`~/.claude/CLAUDE.md` に禁止リスト形式 19.1% で、ほとんど減っていない。前回記事で報告した 21.1% から 8.8% への低下は、期間と本数を広げて測り直すと再現しなかったと訂正している。

次に PR 作成用の /pr skill へ、`git diff HEAD -U0` からコメント行を抽出して 1 行ずつ残す・消すを判定させる手順を追加した。判定表の中身は CLAUDE.md の禁止リストとほぼ同じで、文面は変えていない。結果、1 PR あたりのコメント行数の中央値は 27 行から 21 行、4 行以上続く塊を含む PR は 77% から 65% に下がった。

2026 年 2 月 26 日から GitHub Actions の Artifact を zip 化せずにアップロードできるようになった点を使った運用の紹介。`actions/upload-artifact@v7` の `archive: false` を指定する（アップロードできるのは単一ファイルのみ）。

単一ファイルの HTML や画像なら Artifact の URL を開くだけでブラウザに表示され、プライベートリポジトリではリポジトリの read 権限で保護される。スクリーンショットは base64 で HTML に埋め込めば、枚数によらず Artifact 1 つ・URL 1 つで済む。

背景として、gh コマンドや GitHub API では PR の説明に画像を添付できず、`--attach` の preview build は執筆時点で正式版に入っていないことが挙げられている。運用は、変更概要のレビューガイドと動作確認レポートを CI で生成し、Bot が URL を PR にコメントする形。

React JSON Schema Form で作られていた管理機能 40 画面を、デザインシステムに沿って React コンポーネント直書きへ作り直した記録。

最初は Main / Test / Backend の 3 エージェントを独立した Claude Code として起動し、セッション間通信で束ねる構成を取ったが失敗した。翌朝には Main Agent が「N 画面中 M 画面終わっています。続けますか？」で停止し、完了したはずの画面もテストや問い合わせが済んでいなかった。compaction で最初の指示が薄れたこと、大量のタスクを同一セッションに渡すと途中で判断を仰いで止まることが原因として挙げられている。

次に ralph-loop へ切り替えたところ、約 1 日で全画面の実装とテストが一巡した。設定ファイルと準備はすべて Claude Code に任せ、最初のプロンプトは移行計画の続きを行いたい旨とエージェント分割の判断を委ねる 2 文だけだった。

決めた時間やイベントをきっかけに Claude Code を自動起動する routine の活用例を 8 件紹介している。トリガーは cron・GitHub イベント・API（webhook）の 3 種で、2026 年 4 月に登場し執筆時点では research preview。

実行環境はクラウドとローカルから選べるが、クラウド実行はローカルの skill やメモリを読み込まないため、使わせたいものはリポジトリに置いて明示的に参照させる必要がある。実行は所有者アカウントの usage を消費し、定額プランならその範囲で動く。GitHub Actions から従量課金の API で回すと 1 回 5 ドルかかるコードレビューも定額で実行できるとしている。

具体例は、毎朝 6 時に一言返すだけで 5 時間の利用枠を開始させる routine、平日日中に 1 時間おきにセッション名を「リポジトリ名/作業内容」へ揃える routine、週次でチームの休暇予定を集計して Slack に投稿する routine など。

生成 AI を使って Push 通知機能の設計を進めた際、通知対象者 1 人を処理するために最大約 11 回 DB へ問い合わせる構造になっていたという記録。100 人で約 1,100 回、1,000 人で約 11,000 回になる。

個々の処理（対象者の確認、通知条件の確認、端末情報の取得、通知済みの確認、結果の保存）はいずれも自然だが、対象者ごとに繰り返すと問い合わせ回数が人数に比例して増える。Push 通知自体は対象者ごとに送る必要があるが、必要な情報をまとめて取得し、結果もまとめて保存する形に変えられる。

本番障害ではなく設計段階で気づいた話であり、AI 固有の問題でもないと明記している。開発速度が上がるぶん「100 人なら」「1,000 人なら」「ループ内で DB アクセスしていないか」を別途確認する必要があり、性能面だけを監査させるレビューも有効だとしている。

Anthropic が 2026 年 7 月 24 日のブログで、Claude Opus 5 / Fable 5 向けに Claude Code のシステムプロンプトを 80% 以上削っても社内コーディング評価で性能低下を測定できなかったと公表した点を起点にしている。制約の多くは最悪のケース回避のために入れたもので、今のモデルは周囲の文脈から判断できる、という理由づけである。

同じことが CLAUDE.md にも当てはまるとして、旧世代向けに積んだ禁止ルール・手順の全文・使い方の例示が判断の邪魔になったり互いに矛盾したりする可能性を指摘する。実際に「必要に応じてドキュメントを残す」と「コメントを追加してはならない」が 1 リクエスト内に同居していた例が挙げられている。

記事は見直しの 7 ステップ、それをワークフロー化したスキルのコード、全体用 1 つとプロジェクト種類別 6 つの CLAUDE.md 例を載せる。削ってはいけないものとして、不可逆な操作の確認ゲートと、リポジトリを見ても分からない罠を挙げている。

未経験から IT 業界への転職を目指す人から「アピールできることがない」「特別な資格も実績もない」という相談を多く受ける、という採用広報担当者の記事。

販売職の例として「レジ対応 品出し お客様対応」という記述と、「混雑する時間帯にレジの待ち時間が長くならないよう、周囲の状況を確認しながら応援を依頼し、お客様への案内も行っていた」という記述を並べ、後者からは働き方が読み取れると説明している。

同じミスを防ぐため確認方法を変えた、新人向けに手順をまとめた、よく聞かれることの説明を工夫した、といった本人が「普通」と考えている行動にこそ見たいものがあるとしている。数字で表せる成果がなくても、新人から質問されるようになった、難しい客の対応を任されるようになったといった変化も経験の一部だと書いている。

月次セキュリティチェックで、担当者が複数の提出物と申請状況を確認し未対応者に個別リマインドしていた運用を自動化した記録。所要は 15 時間 55 分から 8 時間へ、7 時間 55 分・約 49.7% の削減。

対象業務は 3 つ。モバイル PC の持ち出し申請の確認（機器情報や管理番号の正しさまで確認）、モバイル PC 設定の第三者チェック（指定フォルダへのログ提出の有無と内容）、作業品質・セキュリティチェックシートの提出確認。

課題は、情報が Box・Excel・Power Apps・SharePoint Online に分散していること、リマインドが Teams の個別対応に依存していること、提出有無と内容確認が重複していることの 3 点。Power Automate で自動リマインド、Power Apps で提出状況の一覧表示と手動リマインド、申請内容と管理情報の自動突合を実装している。

薬学部卒・製薬メーカー営業 6 年・薬局薬剤師 2 年の経歴から、CCNA・基本情報・応用情報を取得して IT エンジニアへ転職したが、2 か月で解雇された経緯の記録。

2026 年 6 月から EDR 製品を扱うスタートアップでフルリモートの研修を受け、1 か月区切りのハンズオンテストのうち 2 個目（EDR 製品の基本操作）が振るわず能力不足と判定された。当時は CISSP の受験を控えて資格勉強に時間を割いており、退勤後や土日に研修内容を復習していれば違ったのではないかと振り返っている。

2026 年 8 月から Openwork・Green・エージェント経由で 40 社ほど応募し、10 社が書類通過、5 社から内定。年収レンジは 400 万〜550 万で、受託 SIer に決めている。短期離職についてもきちんと話せば受け入れられたと書いている。

Amazon Bedrock AgentCore Gateway 自体は送信元 IP を固定する仕組みを持たないため、Lambda をプライベートサブネットに置き、単一の NAT Gateway 経由で送信元 IP を固定する構成を検証した記録。

経路は、IAM 認証で Gateway をローカルから呼び、Gateway が VPC 内の Lambda を呼び、Lambda が Secrets Manager から API キーを取得して Elastic IP で固定された Regional NAT Gateway 経由でリクエストを送り、送信元 IP と API キーで認証する API Gateway に到達する形。

CDK（TypeScript）では、パブリックサブネットを作らず PRIVATE_ISOLATED のみの 2AZ 構成にしている。Regional NAT Gateway を Manual Mode で 1 つの AZ にだけ EIP を割り当てると auto-expansion が無効化され、他 AZ のトラフィックもその AZ 経由でクロス AZ ルーティングされるため送信元 IP を 1 つに固定できる（クロス AZ のデータ転送コストは発生する）。API キーの管理は当初 AgentCore Identity の ApiKeyCredentialProvider を想定したが取れず、Secrets Manager に置いている。