生成AIを開発に利用するとき、「どのAIモデルが最も優秀か」という比較に目が向きがちです。 しかし、実際の開発では、AIモデル単体の性能だけで開発効率や品質が決まるわけではありません。 重要なのは、 どの開発ツールから、どのAIエージェントを使い、どのモデルに何の役割を担当させるか という組み合わせです。 現在、私の開発環境は、次の2系統で構成しています。 メイン環境： Ghostty＋Herdr＋Claude Code CLI 予備・バックアップ・事前調査環境： Zed＋Z.ai、またはZed＋Sakana AIのFugu Ultra メイン環境では、Claude CodeのOpus 4.8を実装担当として利用し、 Codexを独立したレビュー担当として組み合わせています。 この記事では、私がこの構成を選んでいる理由と、 AIモデル、AIエージェント、開発ツール、レビュー規約を どのように組み合わせているかを紹介します。 １．AIモデル、AIエージェント、開発ツールは別物 まず、混同されやすい用語を整理します。 分類 役割 私の環境での例 開発

社内のコードとログを海外のLLM SaaSに送らずに、エディタでAIコーディングを使いたい。 この当たり前の要望が、実は技術的にかなり難しいという話と、それを2つのクラウドで実測して白黒つけた記録です。 生成AIをコーディング業務に組み込むとき、多くの企業が最初にぶつかる壁が 「入力したコードや社内ログが、海外のデータセンターで処理されるのではないか」という懸念です。 いわゆるデータ越境リスク。契約や規約で「学習には使わない」と書かれていても、 物理的にどのリージョンで推論(inference)が実行されるかは別問題として残ります。 私たちはこのテーマに対して、2つのクラウド上で検証リポジトリを作り、 「書類上できるはず」を一切信用せず、すべて実測で判定するという方針で取り組みました。 本記事はその2つのリポジトリ ― Azure版の editor-openai-foundry と、 AWS Bedrock版の editor-claude-bedrock ― をたどりながら、推論の国内完結がどこまで実現できるのかを整理します。 この記事で答えるこ