GenAI週刊 2025年12月13日号
今週のAI・コーディング関連の重要な動向をお届けします。
今週のハイライト
2025年12月、AI開発エコシステムは重要な分岐点を迎えています。今週の動向からは、標準化による相互運用性の追求、AI時代におけるコード品質の再定義、そしてAIの限界への冷静な認識という、3つの重要な潮流が明確に見えてきます。
MCP（Model Context Protocol）がLinux Foundationに加入し、JetBrainsがACP（Agent Client Protocol）のベータ提供を開始したことは、AI開発ツールの断片化問題に対する業界の本格的な取り組みを示しています。GoogleもMCPの公式サポートを発表し、エージェントAI財団の設立により、オープンで協調的なエコシステムの構築が加速しています。これは、特定ベンダーに依存しない、持続可能なAI開発基盤の確立を目指す動きであり、開発者にとって長期的な投資の安全性を高めるものです。
一方で、AIによるコード生成速度の向上が、必ずしも品質向上を意味しないという認識も広がっています。GitHubは「スピードと品質はトレードオフではない」と主張し、GitHub Code Qualityのような新しいツールを通じて、AI時代のコード品質管理手法を提案しています。CyberAgentやUbie、エウレカといった国内企業の事例は、AIを活用しながらも、明確なルールとレビュープロセスを通じて品質を担保する実践知を示しています。
さらに注目すべきは、AIの限界に対する冷静な視点の台頭です。リチャード・ストールマンは「ChatGPTはでたらめ生成器に過ぎない」と断じ、馬の事例を引用した論考は「AIによる仕事の代替が予想以上に急速に進む可能性」を警告しています。しかし同時に、「AIはコードを書けるが、仕事は奪えない」という論調も示されており、エンジニアの真の価値は判断力や問題解決といった非プログラミングスキルにあるという認識が共有されつつあります。
今週の動向が示すのは、AIツールの成熟と、それを使いこなすための組織的・技術的な知恵の蓄積が同時に進んでいる状況です。標準化された基盤の上で、品質を維持しながら、AIの限界を理解した上で活用する。このバランス感覚こそが、AI時代の開発者に求められる本質的なスキルと言えるでしょう。
1. MCP & エージェント基盤の標準化
MCPがLinux Foundationに加入：次世代AIツールとエージェントを構築する開発者にとっての意味
https://github.blog/open-source/maintainers/mcp-joins-the-linux-foundation-what-this-means-for-developers-building-the-next-era-of-ai-tools-and-agents/
Model Context Protocol (MCP)がLinux Foundation傘下のAgentic AI Foundationに加入し、AIツールやエージェント開発における断片化された統合問題への標準的な解決策を提供します。
近年、AI開発は爆発的な成長を遂げ、GitHub上では110万以上のパブリックリポジトリがLLM SDKをインポートし、約70万の新規AIリポジトリが作成されました。vllmやollamaのようなエージェントツールは現代の開発スタックに急速に組み込まれています。このような背景の中で、モデルと外部システムをセキュアかつ一貫して、プラットフォーム横断的に接続する必要性が高まりました。この課題を解決するために登場したのがModel Context Protocol (MCP)です。
Anthropicの社内プロジェクトとして始まったMCPは、当初からオープンであることで急速に普及し、GitHubやMicrosoftなどの企業もその開発に貢献しました。今回、AnthropicはMCPをLinux Foundationが管理するAgentic AI Foundationに寄贈し、プロトコルは共同管理の新たな段階に入ります。これにより、開発者は長期的なツール、本番エージェント、およびエンタープライズシステムのための強固な基盤を得ることができます。
MCP登場以前は、LLMと外部システムを接続するには、互換性のないAPI、独自拡張、IDEプラグインなどが混在し、いわゆる「n×m統合問題」として知られる複雑な状況に直面していました。この問題は、各モデルクライアントが、開発者が依存する各ツールやサービスと個別に統合する必要があることを意味し、非効率的でイノベーションの妨げとなっていました。
MCPは、モデルとシステムが互いに通信し、コンテキストを要求し、ツールを実行する方法を標準化することでこの問題を解決します。セキュアなリモートサーバーを可能にするOAuthフロー、一貫したモデル動作を保証するサンプリングセマンティクス、長時間のタスクを追跡するためのAPIなど、重要な機能がコミュニティによって追加されてきました。特に、OAuthの導入は、エンタープライズ環境でのMCPの利用を可能にし、既存の認証スタックへの統合を容易にしました。また、MCP Registryは、開発者が高品質なサーバーを発見し、企業が利用を管理するための手段を提供しています。
Linux Foundationへの移行は、MCPが真の業界標準としての成熟度に達したことを示しています。これにより、プロトコルの長期的な安定性、すべての参加者による平等な貢献、互換性の保証、およびオープン標準としての安全性が確立されます。開発者にとっては、「一つのサーバーで多くのクライアントに対応」「予測可能でテスト可能なツール呼び出し」「エージェントネイティブなワークロードへの対応」「セキュアなリモート実行」といった具体的な利点があります。
GitHubのOctoverseレポートが示すように、AI開発は主流になりつつあり、エージェントワークフローは急速にエンジニアリングに浸透しています。MCPは、開発者が既存のAPI設計や分散システムで慣れ親しんだパターンと整合しており、ベンダーロックインや独自拡張なしにエージェント、ツール、ワークフローを構築するための安定したオープンな基盤を提供します。次世代のソフトウェアがモデルだけでなく、モデルとシステムの相互作用によって形成されることを考えれば、MCPはその接続組織となることが期待されています。
エージェントAI財団が発足：オープンソースで自律型AIエコシステムを推進
https://block.xyz/inside/block-anthropic-and-openai-launch-the-agentic-ai-foundation
Block、Anthropic、OpenAIといった業界の主要企業が協力し、自律的に行動するエージェントAIのオープンで協調的なエコシステムを育成するため「Agentic AI Foundation (AAIF)」を設立しました。
Block、Anthropic、OpenAIらがLinux Foundation傘下で「Agentic AI Foundation (AAIF)」を発足させました。これは、人間の指示を最小限に抑え、自律的に意思決定し行動する「エージェントAI」のオープンで協調的なエコシステムを推進するための重要な取り組みです。AAIFは、単一企業が支配しないベンダーニュートラルな環境を提供し、オープンプロトコルを通じて異なるビルドシステム間のシームレスな連携を可能にすることを目指します。
本記事は、エージェントAIが今後数十年で最も大きな技術変革の一つであり、ソフトウェア開発、ビジネス運営、問題解決の方法を根本的に変えうると強調しています。しかし、そのポテンシャルを最大限に引き出すためには、オープンで相互運用可能なインフラを構築することが鍵となると主張しています。もしオープンな共同開発が進まなければ、技術が断片化し、少数の企業に力が集中し、競争が阻害され、アクセシビリティが制限されるリスクがあると警鐘を鳴らします。過去のインターネットやLinux、Webの成功がオープン性によってもたらされたことを引き合いに出し、エージェントAIも同様の機会を得るべきだと訴えています。AAIFは、WebにおけるW3Cのように、相互運用性、オープンアクセス、選択の自由を保証する標準とプロトコルを提供することを目指しています。
AAIFは、透明性のあるガバナンスモデルの下で、企業、研究者、独立した開発者がオープンソースのエージェントAIプロジェクトで協力できる中立的な場を提供します。初期の貢献プロジェクトとして、BlockのオープンソースエージェントAIフレームワーク「goose」、AnthropicのAIシステムと外部データソースの統合を可能にするオープンプロトコル「Model Context Protocol (MCP)」、そしてOpenAIのコーディングエージェント向けオープンフォーマット「AGENTS.md」がAAIFの管理下に移行します。これらは、開発者がエージェントAIシステムを構築し、相互に連携させる上での基盤となることが期待されます。
エージェントAIの未来をオープン、アクセス可能、コミュニティ主導にすることで、誰もが強力なツールから恩恵を受け、最高のアイデアがどこから生まれても成功できるエコシステムを創造することが、AAIFの究極の目標です。ウェブアプリケーションエンジニアは、この動きを注視し、今後のオープン標準やツールの開発に積極的に参加することで、自身の開発ワークフローやプロジェクトに大きな影響をもたらす可能性を秘めています。
2025年12月版: MCP、Subagent、Skills… エージェント拡張技術が次々出てきて追いきれない人のためのガイド
https://qiita.com/jugyo/items/afd684d7eeb0bf194843
Anthropicが提唱するAIエージェント拡張技術（MCP、Subagent、Skillsなど）の進化を、各技術が解決しようとした課題の観点から時系列で解説します。
この記事は、Anthropicの公式ブログを基に、AIエージェントの拡張技術がどのような課題を解決するために登場したのかを時系列で整理したガイドです。エージェント技術が急速に進化する中で、各技術の背景を理解することで全体像を把握することを目的としています。
まず、2024年11月にMCP (Model Context Protocol)が発表されました。これは、LLMと社内データベース、SaaS、開発ツールなどの外部システムとのカスタム統合が乱立し、メンテナンスとスケールが困難になる問題を解決するために、「AIアシスタントと外部システムをつなぐオープン標準」として提案されました。AI側をMCPクライアント、外部システム側をMCPサーバとすることで、接続の共通プロトコルを確立しました。
MCPにより外部システムと接続できるようになると、今度は1体のエージェントが全てをこなすことによるプロンプトやコンテキストの肥大化、設計・デバッグの複雑化が問題となりました。これに対し、2024年末〜2025年前半にかけてSubagentと呼ばれるマルチエージェント構成が解決策として登場します。リーダーエージェントが全体方針とタスク分割を行い、複数のサブエージェントがそれぞれ独自の観点やツールでリサーチを進め、要約のみをリーダーに返すことで、コンテキスト負荷と設計の複雑性を分散します。
2025年9月には、コンテキストウィンドウの圧迫が本格化し、プロンプトだけでなく過去の会話履歴、MCPツール定義、実行結果、Subagentからのレポートなどが積み重なる問題が生じました。そこでAnthropicは「何をコンテキストに入れるか／残すか／外に出すか」を扱うコンテキストエンジニアリングの概念を提唱。要約（コンパクション）や構造化された外部ノート（メモリ）、Subagentによる窓口分割といった手法が示されました。
さらに、業務固有の手続き的知識が大量に必要となる一方で、それを全てシステムプロンプトに書き込むことの扱いにくさ、更新の難しさが問題となります。この課題に対応するため、2025年10月にはAgent Skillsが登場しました。Skillは、説明・手順を含むSKILL.mdと追加ファイルで構成される「知識パッケージ」であり、エージェントは必要に応じて段階的に知識を読み込むことで、コンテキストの節約とノウハウの活用を両立させます。
2025年11月4日には、ツール定義だけで数万トークンに達するケースや、ツール呼び出しによる中間結果の蓄積がコンテキストを埋め尽くす問題に対し、Code execution with MCPが発表されました。これはMCPプロトコル自体は変えず、エージェントがMCPツールをPythonコードから呼び出せるAPIとして扱うことで効率化を図ります。必要なツールファイルだけを読み込んでコードを生成し、データ加工をコード側で完結させることで、全てのツール定義をコンテキストに展開する手間や中間結果の肥大化を防ぎます。
そして、その約3週間後の2025年11月24日には、ツール定義や中間結果によるコンテキスト肥大化問題へのより体系的なアプローチとしてAdvanced tool useが発表されました。これは、必要なツール定義だけを検索してロードする「Tool Search」、モデルがPythonコードを書いて複数のツールを呼び出し処理する「Programmatic tool calling」、スキーマだけでは伝わりにくいツールの正しい使い方を具体例と共に提供する「Tool use examples」の3つの主要なポイントから構成され、ツールの効率的な利用を推進します。
これらの技術は、MCPが外部接続の可能性を開いた後、エージェントがコンテキストの重みで身動きが取れなくなるという新たな課題に対して、コンテキスト管理の解決策として次々と生み出されてきました。それぞれの技術が「どんな問題を解決しようとしているのか」という視点で理解することが、キャッチアップの鍵であるとまとめています。
GoogleサービスでModel Context Protocol (MCP)の公式サポートを発表
https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services?hl=en
Googleは、AIエージェントがGoogleの各サービスや企業のAPIを容易に利用できるよう、Model Context Protocol (MCP)の公式サポートとマネージドサーバーの提供を開始しました。
Googleは、AIモデルが実際のツールやデータと確実に連携し、複雑なマルチステップタスクを実行する「エージェント」としての能力を向上させるため、Model Context Protocol (MCP)の公式サポートを発表しました。これまで開発者は個別のMCPサーバーを管理する必要があり、実装が脆くなりがちでしたが、今回Googleの既存APIインフラストラクチャにMCPを組み込み、フルマネージドのリモートMCPサーバーとして提供することで、開発者の負担を軽減し、より堅牢なAIエージェントの実装を可能にします。
この新機能は、Google Maps、BigQuery、Google Compute Engine (GCE)、Google Kubernetes Engine (GKE)といった主要なGoogleサービスから段階的に展開されます。例えば、Google Maps PlatformのMaps Grounding Liteを通じて、AIエージェントは地理空間データにアクセスし、現実世界の場所や旅行に関するクエリに正確に回答できます。BigQuery MCPサーバーは、データ移動なしで企業データに対するクエリ実行を可能にし、セキュリティとレイテンシーのリスクを軽減します。GCEおよびGKEのMCPサーバーは、インフラストラクチャのプロビジョニング、サイズ変更、コンテナ操作を自律的に管理する能力をAIエージェントに与え、開発者が複雑なCLIコマンドを組み立てる手間を省きます。
さらに、Apigeeを通じて企業の既存APIスタックにもMCPを拡張することで、組織は自社の開発したAPIやサードパーティAPIを、エージェントが利用可能なツールとして公開・管理できるようになります。これにより、開発者は、BigQueryで売上データを予測しながらGoogle Mapsでビジネスロケーションを調査するといった、より高度なシナリオを容易に構築できます。
Googleは、Cloud API RegistryとApigee API Hubを通じたツールの発見性、Google Cloud IAMによるアクセス管理、監査ログによる可観測性、Google Cloud Model Armorによる脅威防御といったセキュリティとガバナンス機能も強化しています。MCPサポートの拡大により、開発者がエージェントとデータやアクションを容易に連携させ、AI革命を推進するエコシステムの構築に貢献し、開発者が次のイノベーションに集中できるようになると強調しています。
AIエージェントをどのコードエディタでも使えるようにする「ACP（Agent Client Protocol）」、JetBrainsがベータ提供開始
https://www.publickey1.jp/blog/25/aiacpagent_client_protocoljetbrainszeddocker.html
JetBrainsは、ZedやDockerと共に、AIエージェントとコードエディタ間の相互運用性を高める業界標準プロトコル「Agent Client Protocol (ACP)」のベータ版をJetBrains IDEsで実装し、提供を開始しました。
JetBrainsは、AIエージェントを任意のコードエディタや開発ツールで利用可能にするための業界標準プロトコル「Agent Client Protocol (ACP)」のベータ版を、同社のJetBrains IDEsに実装し、提供開始したことを発表しました。この取り組みは、Zed、Dockerといった主要な開発ツールベンダーが主導しており、プログラマの指示により自律的にコーディングを行うAIエージェントが特定の開発環境に縛られずに機能することを目的としています。
現代のAIエージェントの多くは、Visual Studio CodeやClaude Codeなど特定の開発ツールと深く統合されていますが、ACPはこうした制限を取り払い、開発者が愛用するエディタと好みのAIエージェントを自由に組み合わせられるようにすることを目指します。これは、コード補完機能の事実上の標準となったLanguage Server Protocol (LSP)が、どの開発ツールでもコード補完を可能にした成功例をAIエージェントの分野で再現しようとするものです。
ACPはすでにZedやDockerによって実装されており、AIエージェントとしてはClaude Code、Codex CLI、Gemini CLI、OpenCode、OpenHands、Dockerのcagentなどがサポートしています。この標準化されたプロトコルの普及により、ウェブアプリケーションエンジニアは開発環境の選択肢が広がり、AIエージェントを活用したコーディングの柔軟性と効率が大幅に向上することが期待されます。特定のツールに依存することなく、最適な組み合わせで開発を進められるようになる点は、今後の開発ワークフローに大きな影響を与えるでしょう。
2. AI時代のコード品質管理
制御なくしてスピードは意味をなさない：AI時代にコード品質を高く保つ方法
https://github.blog/ai-and-ml/generative-ai/speed-is-nothing-without-control-how-to-keep-quality-high-in-the-ai-era/
AIがコード生成を加速させる一方で、GitHubは、新たに公開プレビュー中のGitHub Code Qualityなどのツールと、明確な指示・思考の可視化戦略を通じて、品質を犠牲にすることなく開発者が高速かつ信頼性の高いソフトウェアを構築する方法を提示します。
AIの活用により開発速度は飛躍的に向上しましたが、明確な方向性やガードレールなしにAIを使用すると、「AIスロップ」と呼ばれるコンテキストを欠いた半機能的なコードが生じ、バグや技術的負債を蓄積するリスクがあります。GitHubは、このAI時代において、スピードだけでなく「コントロール」が不可欠であり、品質と速度はトレードオフではなく、互いに補強し合う関係にあると主張します。開発者がコード品質を高く保ちながら高速開発を実現するための3つの戦略を提案しています。
1. スピードと品質を一体として扱う: AIが生成するコードは一見洗練されていても、潜在的な問題を抱えていることがあります。これに対処するため、GitHubはAIとCodeQLを組み合わせた分析ツール「GitHub Code Quality」（現在公開プレビュー中）を紹介します。このツールは、リポジトリレベルで有効化することで、コードベースの保守性や信頼性の問題を検出し、プルリクエスト内で未使用変数や重複ロジックなどの問題に対するワンクリック修正提案を自動で行います。さらに、ルールセットを使って品質基準を強制し、AI Findingsページで既存の技術的負債を可視化して修正を促すことで、AIによるスピードとGitHub Code Qualityによるコントロールを両立させ、品質を犠牲にすることなく開発を進めることを可能にします。
2. AIの乗客ではなく、ドライバーとなる: AIは実行を加速させますが、高品質なコードは自動化だけでは生まれません。GitHubは、開発者がGitHub CopilotやGitHub Code Qualityを活用して最高のコードを書くためのツールを提供しつつ、AIに対する明確な指示の重要性を強調します。良いプロンプトは、単なるアクションの指示に留まらず、「可読性と保守性を向上させるリファクタリング」のように具体的な「目標」を設定し、第三者依存の禁止や後方互換性などの「制約」、関連ファイルやドキュメントなどの「参照コンテキスト」、そしてプルリクエストや差分などの「出力形式」を明確にすることが重要です。これにより、人間の思考の責任とAIの実行の責任が明確になり、高品質なソフトウェアの加速につながります。
3. 出力だけでなく、思考の明確な証拠を残す: AIがコード生成の実行タスクをより多く担うにつれて、開発者にとって重要なのは、意思決定、トレードオフ、および問題へのアプローチ方法を明確に伝える能力になります。コードだけでなく、思考プロセスを可視化するためのベストプラクティスとして、問題、成功の定義、制約、リスクをまとめたIssueの作成、意図を伝えるブランチ名とコミットメッセージの使用、そしてAIを使った後でもなぜそのアプローチを選んだのか、どのような代替案があったのかを短いメモで残すことなどが推奨されています。プルリクエストには「Why」「What changed」「Trade-offs」といったコンテキスト豊富な情報を加えることで、コードが「何をしたか」を示すのに対し、ドキュメントは「なぜそれが重要か」を伝え、AI時代における開発の品質と信頼性を高めます。
Claude Code GitHub Actions で Dependabot が作成した PR を自動マージ
https://developers.cyberagent.co.jp/blog/archives/60598/
CyberAgentは、Claude Code GitHub Actionsを活用し、Dependabotが作成するPRをAIでレビューして安全に自動マージするワークフローを構築しました。
本記事では、CyberAgentがDependabotによる依存パッケージのバージョンアップPRの自動マージを、AIを活用して安全に実現した事例を紹介しています。大規模システムでは依存パッケージが多く、セキュリティ維持のためには定期的な更新が不可欠ですが、全てのPRを手動で確認するのは開発者にとって大きな負担です。多くのDependabot PRは軽微な変更であり、安全にマージできるため、この手作業の自動化が求められていました。
著者は、「そのままマージしても安全にリリースできるPR」の条件として、「patch/minorバージョンアップ」「信頼できる開発元」「CI通過」「破壊的変更なし」「利用中の関数への影響なし」の5つを定義。このうち最初の2つはGitHub Scriptによるルールベースで判定し、残りの「破壊的変更なし」「利用中の関数への直接的な影響なし」の2点を、Claude Code GitHub Actionsを用いたAIレビューで判断するハイブリッドなワークフローを設計しました。
具体的には、ルールベースの条件が満たされた場合にPRのAuto Mergeを有効化。その後、Claude Code GitHub ActionsがPRの変更内容を詳細にレビューし、破壊的変更の有無やコードの実際の利用箇所への影響を評価します。安全であると判断されればAIがPRを承認し、CIが通過した時点で自動マージが実行される仕組みです。プロンプトには、レビューの観点、禁止事項、出力フォーマット、そして承認コマンド「`gh pr review -a`」の使用方法が詳細に指示されています。
このシステムにより、安全と判断されたPRはDependabot作成からわずか2分でマージされるケースが確認され、開発者のレビュー負荷が大幅に軽減されることが実証されました。信頼できないパッケージのPRは意図通りスキップされ、安全性が担保されています。著者は、生成AIが「要件は明確だがルールベースでは判断しにくい」タスクの自動化を可能にする一方、この成功は充実したCI/CDやデプロイフローといった、従来のソフトウェアエンジニアリングのベストプラクティスが基盤として存在していたからこそ実現できたと強調しています。
AIエージェント開発のカオスを防ぐ「保証駆動開発」の思想を提示
https://techtekt.persol-career.co.jp/entry/tech/251209_02
AIエージェントを活用した開発で直面する「コンテキスト汚染」と「出力のゆらぎ」を構造的に解決する「Guarantee-Driven Development（保証駆動開発、GDD）」の概念を提唱します。
AIエージェントを用いた開発では、プロンプトが同じでも出力がブレたり、古い仕様が参照されたりする「コンテキスト汚染」と「出力のゆらぎ」が課題となります。著者は、人間が文脈で判断できる情報の有効性をAIが区別できないため、古いPoCのノイズや不完全な設計メモが正式な仕様と同じ重みで参照され、プロジェクト全体の整合性が崩れていくと指摘します。
この問題に対処するため、著者は「Guarantee-Driven Development（保証駆動開発、GDD）」という情報構造アーキテクチャを提案しています。GDDは以下の要素で構成されます。
1. SSoT（Single Source of Truth／正式仕様）: AIが参照する唯一の真実源。曖昧さを排除し、if/thenや真理表などで機械可読性を最優先で定義します。人間はAIに要約を求める役割に徹します。
2. DR（Decision Record／判断記録）: AIの誤補完を防ぐため、判断の意図と境界を保存します。前提条件、採用・棄却された選択肢、そして廃棄条件を明記し、SSoTが「何が正しいか」を、DRが「なぜそうなのか」を分担します。
3. Mini-PoC（隔離箱）: PoCコードは「破棄前提」の隔離箱として扱い、そこから得られた知見のみをSSoTとDRに還元します。PoCで生まれたノイズが本番環境に混入するのを構造的に防ぐため、コード自体は破棄し、正式実装はゼロから再生成することを徹底します。
さらに、AIの確率的な出力の「ゆらぎ」に対処するため、Purity（純度）、Context（文脈）、Safety（安全）の三層構造による誤り訂正的な発想を導入します。Purity層はSSoT管理とMini-PoCによるコンテキスト汚染防止、Context層はDRによる文脈保存、Safety層はContract Testやモニタリングによる仕様巻き戻りや意図しないスコープ拡大の検出・補正を担います。
このGDDは、コード作成コストが低減するAI時代において、仕様定義、コンテキストの清潔さ維持、ゆらぎ検知・訂正のコストが相対的に重くなる状況に対応するものです。特に、中〜大規模かつ長期的なAIエージェント開発において、複雑化する情報と人の入れ替わりの中でプロジェクトの正しさを長期的に保証する上で真価を発揮すると著者は主張しています。
Claude Codeプラグインを社内で作って、2ヶ月経過したUbie テックブログ
https://zenn.dev/ubie_dev/articles/5c510ab1d7e6f3
Ubie社は、Claude Codeプラグインの社内マーケットプレイスを迅速に立ち上げ、マルチエージェント型意思決定支援「magi」やコードレビュー「mr」などの独自開発プラグインを通じて、開発体験の向上とセキュリティ強化を実現しました。
Ubieは、Claude Codeのプラグイン機能発表の翌日に、社内向けプラグインマーケットプレイス「claude-plugins」リポジトリを立ち上げ、その2ヶ月間の活用状況を共有しています。このリポジトリは、MCP（Multi-Agent Collaboration Protocol）設定の一元管理を目的とし、古いドキュメントや野良プラグイン接続のリスクに対応することで、セキュリティと管理の効率化を図っています。
特に重要な取り組みとして、プラグイン定義ファイルは英語で記述するルールが導入されました。これは、AIが日本語を英語に変換する際に意図しない挙動を示すことが判明したためで、生成AIが英語で理解・処理することを踏まえ、最初から英語で入力することで、AIの応答精度を劇的に向上させていると著者は述べています。
記事では、著者自身が開発した二つの主要なプラグインが紹介されています。一つは、Gitワークフローを簡略化する「sync-main」プラグインで、変更の確認、一時退避/コミット、そしてメインブランチへの切り替えと最新状態への同期を自動化し、開発者の日々の手間を大幅に削減します。
もう一つは、マルチエージェント型意思決定支援システム「magi」です。これは、科学者、母、現実主義者の3つの専門AIエージェントが並列で分析を行い、技術的、倫理的、実践的な多角的な視点から総合的な結論を提示します。著者はこのプラグインを通じて、エンジニアが陥りがちな論理的思考のバイアス（特に「開発者の負担や保守性」を考慮する「母の観点」の欠如）に気づき、DEI（多様性、公平性、包摂性）の重要性を認識したと述べています。このシンプルなプラグインが、バランスの取れた意思決定に絶大な効果を発揮し、時にはスラッシュコマンドなしでも自然に機能することで、開発者の信頼できる相棒のような存在になっていると強調されています。
さらに、「mr（Multi-Review）」は、多角的なコードレビューを行うマルチエージェントプラグインです。変更されたファイルの言語を検出し、言語別・観点別の専門レビュワーがコードを並列でレビューします。自動修正モードでは、開発者の承認なしに最大5回まで修正を繰り返すことで、開発者のコードレビュー負担を軽減し、コード品質の向上に貢献しています。
Ubieでは、各エンジニアが「自分の開発体験を良くしたい」という動機で自発的にプラグインを開発し、それを社内で共有するボトムアップの文化が根付いています。この文化が実用的で価値のあるプラグイン群を生み出していると結論付けられており、Claude Codeプラグインの社内活用が想像以上に開発体験を向上させたとし、特にMCPサーバー設定のプラグイン化はセキュリティ面でも非常に有効だと提言しています。
４日間でClaudeにドキュメントを8件書かせて、全てCodeXにレビューさせる開発フローをやって得られた効果と失敗
https://zenn.dev/j____takumi/articles/review_docs_by_codex
AIを活用したドキュメント作成とレビューのハイブリッドワークフローを導入し、開発効率とドキュメント品質を大幅に向上させる。
筆者は、開発ドキュメント作成にClaude (Opus/Sonnet)を、そのレビューにCodeX (GPT-5.1ベース)を組み合わせた独自のAI活用開発フローを4日間実践し、その効果と知見を共有しています。AIを活用した開発では、いきなりコードを書くのではなく、事前に「影響範囲調査書」と「実装計画書」を作成することが重要であると強調し、このプロセスにAIを深く組み込む意義を説いています。
具体的には、Claudeは人間が読みやすい文章生成能力を活かしてドキュメントを作成し、CodeXはソースコード理解に強いため、ドキュメントと実際のコードの整合性チェックや技術的な制約、アーキテクチャの妥当性をレビューする役割を担います。この役割分担により、Claudeが作成したドキュメントの「フロー・前提の誤認識」や「技術的制約の未記載」といったミスをCodeXが鋭く指摘し、修正を繰り返すことでドキュメント品質が飛躍的に向上したと報告されています。
筆者は、合計8件のドキュメントをこのフローでレビューし、平均して1ドキュメントあたり3件の指摘を受けたと述べています。指摘は「フロー・前提の誤認識」「技術的制約の未記載」「テスト影響の考慮漏れ」「DI・アーキテクチャの不整合」「仕様詳細の記載不足」の5つのカテゴリに分類され、特に最初の2つが高頻度で発生しました。Androidアプリ開発の具体的な事例として、データフローの誤認、データモデルの存在確認不足、ViewModelのスコープ共有に関する技術的制約の記載漏れなど、CodeXがコードベースを参照して見つけ出した実践的な指摘が多数紹介されています。
このAIレビュー導入により、人間が手直しするコードの大幅な減少、テストケースの欠如発見、実装手順の正確化、そしてドキュメント品質の安定化というポジティブな効果が得られました。一方で、トークン節約の計画、レビュー時のプロンプトで「新しいファイルを作成すること」や「修正したい目的語」を明確に指示することの重要性、そして最終的な人間のチェックの必要性といった運用上の工夫や失敗例も共有されており、AI連携開発の現実的な課題と対策が示されています。
結論として、筆者はAIを複数組み合わせた開発フローはまだ発展途上であるものの、開発効率向上に確実に寄与すると主張し、具体的なコードパスや前提条件をプロンプトに明記することでレビュー精度がさらに向上することを実践知見として読者に推奨しています。
3. AIの限界と批判的視点
AIと仕事の行方：馬の教訓
https://andyljones.com/posts/horses.html
著者は、蒸気機関による馬の置き換えとコンピューターによるチェス名人の克服に共通する「漸進的な進歩と突然の等価性」のパターンをAIに適用し、自身の職務がAIに驚くほど短期間で代替された経験を通して、AIによる仕事の自動化が予想以上に急速に進む可能性を警告する。
著者は、蒸気機関が200年かけて着実に進歩し、その間馬の数は変わらなかったものの、1930年から1950年の間に米国の馬の90%が突然姿を消した事例を提示する。同様に、コンピューターチェスは40年間着実に進歩し、人間を凌駕するのに10年を要した。これらの歴史的パターンは「漸進的な進歩と突然の等価性」を示している。
このパターンをAIに適用し、著者はAIへの設備投資が着実に倍増しているにもかかわらず、人間にとっての「等価性」は突然訪れたと主張する。Anthropicの研究者である著者は、2024年初頭には新入社員の技術的な質問に月に約4,000件対応していた。しかし、Claudeが2024年12月にその一部の質問に答えられるようになり、わずか6ヶ月後には、彼の担当していた質問の80%が消滅した。現在、Claudeは月に30,000件もの質問に回答しており、これは著者が担当していた質問数の8倍に及ぶ。
著者は、馬がその役割を克服されるまでに数十年、チェス名人が数年かかったのに対し、自身の職務の大部分はわずか6ヶ月でAIに代替されたことを強調する。さらに、そのAIシステムは著者の人件費の1000分の1、地球上で最も安価な労働力よりも安価に動作すると指摘する。この急速な変化と圧倒的なコスト効率は、AIによる仕事の自動化が過去の技術革新よりもはるかに速いペースで、そしてより広範囲にわたって進む可能性を示唆している。著者は、馬が経験したような20年間の猶予期間が得られることを望みつつも、自身の経験から、実際にはそれよりもはるかに短い期間しか残されていないのではないかと警鐘を鳴らしている。この見解は、AIの進歩に対する一般的な認識に一石を投じるものであり、ウェブアプリケーションエンジニアが自身のキャリアパスとスキルの再構築を真剣に考えるべき理由を明確に示している。
ChatGPTを使うべきではない理由
https://www.stallman.org/chatgpt.html
リチャード・ストールマンは、ChatGPTが「知能」ではなく、真実への無関心から「でたらめ生成器」と化しており、そのプロプライエタリな性質がユーザーの計算の自由を侵害するため、信頼すべきではないと主張している。
リチャード・ストールマンは、ChatGPTが「知能」ではないと強く主張し、その根拠を説明しています。彼によれば、「知能」とは特定の領域内で「知る」または「理解する」能力を指しますが、ChatGPTはいかなることも知りも理解もしません。ChatGPTは自身の出力が何を意味するのかを知らず、言葉が意味を持つことさえ認識していないため、真実への無関心から出力を生成する「でたらめ生成器」に過ぎないと述べています。この見解は、他の多くの「生成システム」にも当てはまるとのことです。
著者は、これらのシステムに「知能」を帰する広範な誤りが、何百万もの人々に誤った信頼を生み出していると警告しています。ウェブアプリケーションエンジニアにとって重要なのは、言葉を無心に扱うシステムがその言葉の意味において正確であると信用すべきではないというメッセージです。
さらに、ChatGPTを拒否すべきもう一つの理由として、そのプロプライエタリな性質を挙げています。ユーザーはChatGPTのコピーを入手できず、実行ファイルはもちろんのこと、ソースコードさえも利用できません。サーバーを介してのみ使用できるこの形態は、ユーザーの計算の自由を根本的に侵害するものであると、ストールマンは強調しています。
「自信過剰な愚者」問題：AIに曖昧な「雰囲気」ではなく厳格なルールが必要な理由
https://steerlabs.substack.com/p/confident-idiot-problem
AIエージェントの信頼性向上には、確率的な判断に頼るのではなく、決定論的な「厳格なルール」と検証層が必要であると主張し、そのためのオープンソースライブラリ「Steer」を紹介する。
多くのAIエージェント開発者が直面する「自信過剰な愚者（Confident Idiot）」問題とは、LLMがもっともらしいが誤った情報を確信を持って生成し、開発者がデバッグに時間を浪費することです。例えば、誤ったAPI URLを生成したり、安全でないSQLクエリを見過ごしたりします。筆者は、業界で提案される「LLM-as-a-Judge」のような、確率的なモデルで確率的な出力を評価するアプローチでは、LLMの迎合性やハルシネーションの問題は解決できず、危険な循環依存を生み出すと指摘します。
著者は、AIエージェントを「魔法の箱」ではなく従来のソフトウェアとして扱い、アサーションや単体テスト、決定論的な「False」を返すメカニズムを再導入すべきだと主張します。具体的には、URLの有効性をLLMに尋ねる代わりに`requests.get()`を実行する、SQLクエリの安全性をAST解析で確認する、場所の曖昧さをデータベースでチェックするなど、「厳格なルール」の適用を提案しています。
この課題を解決するため、著者はオープンソースのPythonライブラリ「Steer」を開発しました。Steerはエージェント関数をラップし、`RegexVerifier`や`JsonVerifier`といった「厳格なガードレール」を強制することで、「自信過剰な愚者」によるミスをリアルタイムで捕捉します。これにより、LLMがフォーマットを誤っても、基盤となるコードは実行されません。エラーは記録され、ダッシュボードで修正のためにフラグ付けされます。
Steerの「Teach」ループ機能も特徴的です。エージェントが失敗した場合、開発者は「Teach」をクリックし、特定の修正ルール（例：「システムオーバーライド：マークダウンバックティックは絶対に使用しない」）を注入できます。このルールは次回の実行時にエージェントのコンテキストに挿入され、プロンプトテンプレートの書き換えや再デプロイなしにモデルの動作を「パッチ」できます。
最近リリースされた`steer-sdk v0.2`は、オープンソース（Apache 2.0）であり、ローカルで実行され、APIキーのプライバシーを保護します。これは、感覚的なデバッグに疲れた開発者にとって、より堅牢で予測可能なAIエージェントを構築するための実用的なソリューションを提供します。
4. コンテキストエンジニアリングと開発哲学
OpenEvolve: 進化を通じてLLMにアルゴリズムを発見させる
https://algorithmicsuperintelligence.ai/blog/openevolve-overview/index.html
OpenEvolveは、LLMと進化的フレームワークを組み合わせたオープンソースの進化型コーディングエージェントであり、アルゴリズムの発見を自動化する。
ASI Labs Research Teamが発表したOpenEvolveは、大規模言語モデル（LLM）と進化的計算を統合し、アルゴリズム発見を自動化するオープンソースの進化型コーディングエージェントです。手作業のヒューリスティックや網羅的探索に依存する従来のアルゴリズム発見手法とは異なり、OpenEvolveはLLMの創造的可能性を品質多様性探索フレームワーク（MAP-Elites）内で活用することで、より高度なアルゴリズムの発見を目指します。
OpenEvolveの核となるのは、プロンプトサンプラー、LLMアンサンブル、評価器、プログラムデータベース、コントローラーからなる「進化ループ」です。プロンプトサンプラーは、親プログラムや高パフォーマンスの例、多様なサンプルなどから豊富なコンテキストプロンプトを構築し、LLMアンサンブルがdiffベースの編集または完全な書き換えを通じて候補コードを生成します。評価器はユーザー定義のメトリクスでプログラムを実行し、多段階のカスケード評価やLLMベースのフィードバックもサポート。プログラムデータベースはMAP-Elitesを用いて、複雑性や多様性といった特徴次元に沿って品質と多様性を維持し、コントローラーがこの進化プロセス全体を統括します。
主要な技術革新として、「アイランドベースの進化とレイジーマイグレーション」により、早すぎる収束を防ぎつつ並列探索を可能にします。「MAP-Elites」は、プログラムを特徴次元に沿って分類し、品質と多様性の両立を強制します。「カスケード評価」は、複数の段階で候補をチェックし、効率的にフィルタリングすることで評価コストを削減します。さらに、「ダブルセレクション戦略」では、高フィットネスのプログラムを親として選びつつ、LLMには多様なサンプルをインスピレーションとして与えることで、改善と探索の最適なバランスを実現します。
OpenEvolveは多岐にわたる応用例でその実用性と有効性を示しています。AlgoTuneベンチマークでは、JAX JITコンパイルの321倍、FFTベースの畳み込みの256倍といった劇的な速度向上を自動で発見しました。円充填問題では最先端の結果に匹敵する解を導き、GPUカーネル最適化ではApple Silicon上で8要素SIMDベクトル化や二段階オンラインsoftmaxといった非自明な最適化を実現し、100%の数値精度を維持しつつ性能を向上させました。また、LLMプロンプトの最適化にも応用可能で、HotpotQAベンチマークで+10.69%の精度向上を達成するなど、その汎用性を証明しています。これらの成果は、OpenEvolveが人間による介入なしに高度なアルゴリズムを発見し、多様なドメインで性能を大幅に改善する潜在能力を持つことを示しており、持続的な進化が複合的な利益を生むことが強調されています。本ツールはオープンソースで提供され、ライブラリまたはコマンドラインインターフェースとして利用可能です。
生成AIの入出力品質は「フォーマット」で決まる ― 中間表現とテンプレートの組み合わせ
https://tech.newmo.me/entry/2025/12/09/090000
生成AIの出力品質を安定させるため、中間表現（IR）と出力テンプレートを組み合わせた段階的変換パイプラインの導入が、テストケース生成の精度と網羅性を劇的に向上させることを実証します。
この記事は、生成AIが自然言語の仕様書（PRD/PDD）から直接成果物（例：テストケース）を生成する際に生じる「入力理解の不十分さ」や「出力フォーマットのばらつき」といった課題に対し、中間表現（IR）と出力テンプレートを組み合わせた効果的な解決策を提示しています。
著者は、コンパイラが高級言語を中間表現に変換するように、生成AIにおいても「UseCase IR」と「Test Plan IR」という二段階の中間表現を導入するアプローチを紹介しています。UseCase IRで仕様の構造化を強制し、Test Plan IRでテスト戦略を設計することで、AIが仕様を読み飛ばしたり、重要な制約を見落としたりする問題を根本から解決します。具体的には、UseCase IRのスキーマで必須フィールドを定義することで、AIが必要な情報を漏れなく抽出するよう誘導します。さらに、最終成果物には出力テンプレートを適用し、毎回一貫したフォーマットでドキュメントが生成されるようにします。
このパイプラインの導入により、テストケースのカバレッジが+171%向上し、バリデーション、境界値、代替フローといった重要なテスト項目における漏れがゼロになったと報告されています。また、Test Plan IRを挟むことで、単なる機械的な1:1マッピングではなく、境界値の自動追加や優先度分類など、よりインテリジェントなテスト設計が可能になることが強調されています。
UseCase IRは、仕様の構造化された抽象表現として、テストケース生成だけでなく、E2Eテスト、APIスキーマ、UIコンポーネント、ビジネスロジックなど、様々な用途で再利用可能であることも重要なポイントです。これにより、重複作業の削減、認識のずれ防止、仕様変更時の追跡容易化といったメリットが生まれます。
結論として、生成AIに自由な形式で出力させるのではなく、構造化されたフォーマット（IRスキーマと出力テンプレート）で「何を抽出するか」「どう出力するか」を強制することが、入出力品質を安定させ、開発プロセスの効率と信頼性を高める鍵であると筆者は主張しています。これは、webアプリケーションエンジニアがAIを開発ワークフローに統合する上で直面する具体的な課題に対し、実践的かつ具体的な解決策を提供するものです。
AIエージェント（Claude Code/Codex/Cursor）とのチャット履歴を組織のドキュメント資産にするプロンプト/rules
https://qiita.com/WdknWdkn/items/cac488d84a4e767cae12
AIエージェントとの試行錯誤チャット履歴から、プロジェクトの標準実装ルールや知見を自動生成し、組織のドキュメント資産として蓄積するプロンプトと運用フローを提案します。
本記事では、AIエージェント（Cursorなど）とのチャット履歴を、組織の貴重なドキュメント資産として構造化・自動変換する実践的なプロンプトと運用ルールを詳述します。著者は、チーム開発において繰り返し発生する説明の手間や、AIとの対話で得られた知見が個人のチャット履歴に埋もれてしまう課題意識から、この仕組みを考案しました。
AIとの試行錯誤の履歴には「問題発生→試行錯誤→解決→方針確定」という実践的な知恵が詰まっており、これを構造化することで、高い再現性を持つドキュメントを即座に生成し、文脈を保存できると著者は指摘します。これにより、「開発しながらルールが育つ」状態を実現し、個人の暗黙知化やドキュメント整備の後回しを防ぎます。さらに、構造化されたルールはAIの提案品質を継続的に向上させる効果も期待できます。
プロンプト設計の主な工夫点は以下の通りです。
1. 段階的なヒアリング設計: ユーザーに「対象範囲」「背景整理」「実装方針」「例外対応」「AI提案方針」「レビュー観点」「ファイル名」の7つの質問を順に投げかけることで、必要な情報を体系的に収集し、曖昧さを排除します。
2. 推測・想像の禁止: AIがチャット履歴から事実のみを抽出し、不明点は質問で補完することで、誤った解釈や推測による情報の混入を防ぐガードレールを設けています。
3. そのままコミット可能な出力形式: `.cursor/rules/*.mdc` 形式で、フロントマターメタデータ、表形式の実装方針、具体的なコード例、レビューチェックリストなどを含む、完成度の高いドキュメントを自動生成します。
このプロンプトは、コピー＆ペーストでAIに適用し、チャット履歴を読み込ませ、7つのヒアリングに答えるだけで、プロジェクトルールを自動生成できる5ステップのシンプルな運用フローを提示しています。記事では、ES6モジュール環境でのjQuery併用問題を解決した際の出力事例を具体的に示し、新規実装と既存改修のポリシー、例外対応、AI提案ポリシー、コーディング規約、レビュー・運用ルールが明確に記載されたドキュメントが生成される様子を紹介しています。
本アプローチにより、知識の構造化と共有、AIの提案品質継続的向上、レビューコストの削減、そして再現性の高いドキュメント作成といった価値が得られると著者は強調します。AIとの対話で得た知見をその場限りで終わらせず、チーム全体の資産として活用するための具体的な手法として、その実践を強く推奨しています。
コンテキストの配管
https://interconnected.org/home/2025/11/28/plumbing
AIシステム構築において、ユーザーの意図を正確に捉え、動的でタイムリーなコンテキストを継続的に提供するための「コンテキストの配管」という新たなアーキテクチャ思考が不可欠であると筆者は提唱します。
AIシステムを構築する際、開発者は「意図」と「コンテキスト」という二つの中心概念に深く向き合う必要があります。筆者は、AIがユーザーの目標を人間的な方法で理解し、それに応える「意図」の理解が、スマートフォンがデスクトップを凌駕したように、新しいUIの競争優位性をもたらすと指摘します。AI企業は、ユーザーが意識すらしない意図の発生源に最も近い存在になることで競合を圧倒するため、AI搭載メガネや常時オンのデバイスといったハードウェアへの投資が進んでいます。これは単なる新機能ではなく、アテンションエコノミーの必然なのです。
しかし、AIがこの意図を高い精度で処理するためには、膨大な「コンテキスト」が不可欠です。これにはLLMの持つ世界知識だけでなく、WikipediaやGoogleからの背景情報、使用するツールのドキュメント、ユーザーの過去の行動や時間帯といった個人コンテキスト、さらにはユーザーとAIが共有する暗黙の知識や共通の作業ドキュメント、そしてエージェント自身のセッションコンテキスト（サブタスクの有無、過去の成功・失敗履歴など）が含まれます。LangChainが提唱する「コンテキストエンジニアリング」は、これらの適切な情報とツールを、LLMがタスクを達成しやすい形式で提供するシステムを構築することです。AI企業がユーザーのメールアーカイブや常時オンカメラにアクセスしようとするのも、このコンテキストへのアクセスのためだと筆者は説明します。
「コンテキストエンジニアリング」の概念で不足しているのは、コンテキストが「動的」かつ「タイムリー」であるという点です。コンテキストはユーザーの活動や環境の変化（作業中のドキュメント、新しいメール、天候、ツールの更新など）によって絶えず変化し、その発生源は多岐にわたります。AIはユーザーの意図の発生点に最も近い場所で実行されるべきですが、コンテキストは常にその場所にあるとは限りません。したがって、AIエージェントが迅速かつ効果的に機能するためには、この動的なコンテキストを必要な場所へ、継続的に、効率的かつ鮮度を保って移動させる「配管（plumbing）」のようなアーキテクチャが必要です。
筆者は、Web 2.0時代の「CRUD」アプリケーションがデータベースとウェブページのエンティティと操作に焦点を当てていたのに対し、AIシステムではユーザーが利用可能なコンテキストについて直感的に理解できることが重要だと述べます。コンテキストフローの配管は、単なる技術的効率性だけでなく、ユーザーの期待に合致するものであるべきです。筆者は現在、この「コンテキストの配管」という思考モデルに基づき、Cloudflare上でAIエージェントやサブエージェント間でコンテキストがシームレスに流れるプラットフォームを構築しており、その手応えを感じていると語っています。これは、効果的なAIシステムを構築するための、新たなアーキテクチャ的課題と解決策を示唆しています。
5. 実践事例とツール活用
AIコーディングツールによるデザインとエンジニアリングのギャップ解消
https://uxdesign.cc/productionizing-design-prototypes-addressing-the-design-engineering-gap-with-ai-coding-tools-fb3924f83da1
AIコーディングツールを活用し、デザインとエンジニアリングの間のギャップを埋めるための「シャドウリポジトリ」アプローチにより、デザイナーが動くプロトタイプを迅速に構築し、プロダクト開発の速度と品質を向上させる方法を著者は考察します。
著者は、AIコーディングツールがプロダクト開発におけるデザインとエンジニアリングの間に存在する深いギャップを解消する方法について考察しています。従来の静的なモックアップから機能的なプロトタイプへの移行は多くのチームにとって課題でしたが、著者はこの問題を解決するために「シャドウリポジトリ」という独自のアプローチを開発しました。
このアプローチは、AI生成コードの初期段階が「Vibe Coding」文化における「Dribbbleフェーズ」のように、見た目だけ先行して実製品に繋がりにくいという課題意識から始まりました。著者は、AIをプロトタイプ構築のツールとして使用するだけでなく、プロトタイプ自体にAI機能を組み込むという二つの道を模索。Claude Codeの効率性とSupabaseのMCP（Model Context Protocol）ツールを組み合わせることで、動的なデータとAPI連携を持つ機能的なUIの構築を可能にしました。
「シャドウリポジトリ」とは、本番環境のコードベースに影響を与えることなく、デザイナーが完全なプロダクトコンテキストで機能検証を行うための独立したリポジトリです。これにより、デザイナーはリアルタイムまたはモックデータを使ってアイデアを自由に試行し、コンポーネントのアーキテクチャやエッジケース、データレイヤーの設計を早期に洗練させることができます。特にSupabaseをシャドウバックエンドとして活用することで、実際のAPIを呼び出すリスクやコストなしに、リアルに近いデータ環境を実現しています。
この新しいワークフローにより、著者はデザインファイルを渡す代わりに、本番環境への移行が容易な動作するプロトタイプをエンジニアに提供できるようになり、開発速度が劇的に向上したと述べています。デザイナーはコードを学ぶことでエンジニアとのコラボレーションを深め、システム全体への理解を深めることができ、「デザイナー」から「メーカー」、そして「ビルダー」へと役割が変化すると強調しています。
もちろん、AIコーディングツールには「修正時のループ発生」「不適切なコードパターン」「AIの定型的なUI生成」「過剰なエンジニアリング問題解決」といった課題も伴います。しかし、Claude.mdやClaude SkillsのようなAIツールに明確なルールや条件を定義することで、これらの問題は克服可能であると示唆しています。
著者は、シャドウリポジトリのアプローチは現時点での効果的な「移行フレームワーク」であり、デザインとエンジニアリングの関係を再構築し、より迅速で高品質なプロダクト開発を可能にすると結論付けています。
プロダクションAI機能のフレームワークをLangGraphに完全移行
https://tech.every.tv/entry/2025/12/09/120000
既存のAI機能が抱える複雑なワークフローと責務混同の課題を解決するため、LangGraphへのフレームワーク移行を詳説します。
株式会社エブリーは、デリッシュキッチンが提供する会話形式レシピ検索「デリッシュAI」機能において、プロダクションで稼働するAI機能のフレームワークをフルスクラッチの関数パイプラインからLangGraphへ完全に移行したことを報告しています。
デリッシュAIは公開から1年以上が経過し、機能追加や改善を繰り返す中でワークフローが複雑化し、以下の問題に直面していました。第一に、コアビジネスロジック、LLM呼び出し、ワークフロー、状態管理といったアーキテクチャの責務が混同し、特に並列処理が絡むワークフローは追跡が困難でした。ユーザー入力に基づく分岐処理がワークフローにロジックを持たせてしまい、追加・修正実装の負荷が高い状態でした。第二に、責務が不明確なために変更の柔軟性がなく、処理順序の変更や並列化が困難で、新しい施策や精度改善のためのワークフロー変更がストレスとなっていました。結果として、フルスクラッチでの実装が限界に達し、開発スピードの低下が予測される状況でした。
これらの課題を解決するため、同社は明確な責務分離、ワークフローの変更柔軟性・拡張性、プロバイダ非依存性、型制約、テストのしやすさといった要件を設定しました。その結果、現時点でこれら全ての要素にマッチするLangChainおよびLangGraphを採用しました。特に、2025年10月22日にリリースされたv1.0の安定性も決め手となったと述べています。
LangGraph適用後のアーキテクチャでは、`nodes/`でビジネスロジック、`types/state/`で型安全な状態定義、`workflows/`でワークフローのグルーピングと全体のフロー制御を行うことで、明確な責務分離を実現しました。LangGraphの`State`、`Node`、`Edge`の概念を活用し、サブワークフローを定義することで、処理の再利用性やテスト容易性を向上させ、エッジの向きを変えるだけで並列実行を容易に実現できることも示されています。また、LLMプロバイダの変更に関しても、LangChainのパートナーパッケージを利用することで、適用箇所のライブラリ変更のみで置き換えが可能となります。
著者は、最初からLangGraphを採用すべきだったとは必ずしも言えないとしつつ、フレームワークの思想や解決したい課題を深く理解することの重要性を強調しています。この移行により、明確な責務分離と変更に耐えうる柔軟なコードベースが構築できたと結論付けています。
月額約2ドルで最大8時間の動画を話者分離・文字起こし・LLM分析するAWSパイプライン
https://zenn.dev/ekusiadadus/articles/ek-transcript-stepfunctions-1dollar
著者は、ユーザーインタビュー動画を話者分離、高精度文字起こし、LLMによる構造化分析まで行うフルサーバーレスAWSパイプラインを、月額固定費を最小限に抑えつつ8時間動画を約2.3ドルで処理可能にする設計と実装の全貌を詳細に解説する。
この記事は、ユーザーインタビュー動画の分析において既存の商用サービスやAWS Transcribeが高額な固定費や精度不足といった課題を抱えていることを受け、筆者が月額固定費を極限まで抑えつつ、長時間動画に対応する高精度なサーバーレスパイプラインを自作した経緯と詳細な技術解説を提供しています。
主要な要件として「月額固定費ゼロ」「最大8時間の長時間動画対応」「高精度な話者分離と日本語文字起こし」「LLMによる要約・分析」「低コスト（1動画あたり約1ドル）」「フルサーバーレス」が挙げられています。システムはAWS Step Functionsをワークフロー管理に、AWS Lambdaを各処理の実行環境に用いたフルサーバーレス構成で、Amazon S3への動画アップロードをトリガーにパイプラインが起動します。
技術選定では、話者分離に「pyannote.audio 3.1」、文字起こしに「faster-whisper」、LLM分析に「gpt-5-mini」を採用し、それぞれAWS TranscribeやOpenAI Whisper API、Claudeといった代替案と比較して精度とコスト効率の優位性を強調しています。特に、LambdaのコンテナイメージにMLモデルを含めることでコールドスタート時の問題を解決し、固定費がかかるECS Fargateを避ける選択をしています。
このパイプラインの最大の特徴はコスト効率です。Secrets Manager、ECR、CloudWatch Logsなど最小限のサービス利用により、月額固定費を約1.5〜2ドルに抑制。8時間の動画処理を約2.3ドル（無料枠なし、x86 Lambdaの場合）で完了させることができ、AWS Transcribeと比較して約5倍のコスト効率を実現しています。
実装における具体的な課題とその解決策も詳述されています。例えば、Step Functionsの256KBペイロード制限に対しては、Map Stateの結果を破棄し、S3経由でデータを連携することで回避。PyTorch 2.6+での`torch.load`問題には、pyannote.audioのインポート前にモンキーパッチを適用して対応しています。長時間動画の処理を実現するため、音声を8分チャンクと30秒のオーバーラップで分割し、Map Stateで並列処理しつつ、埋め込みベクトルを用いたクラスタリングで話者をグローバルに統一する工夫が凝らされています。
著者は今後の展望として、Google Meetの自動録画APIとの連携によるさらなる自動化を計画しており、その設計ドキュメントも公開しています。このソリューションは、コストを抑えながら高度な音声・動画分析機能を実現したいウェブアプリケーションエンジニアにとって、非常に実践的な知見と具体的な実装パターンを提供するものです。
8GBメモリでローカルLLMを動かす
https://zenn.dev/kokoa0429/articles/e515ff57d56cc0
限られた8GBメモリ環境でローカルLLMを実用的に動かすため、量子化、Ollama/llama.cppの最適設定、主要なハマりポイントとその解決策を詳細に解説し、Misskey監視ボットの実装例でその有効性を示した。
この記事では、一般的に高スペックなGPUが必要とされがちなローカルLLM環境を、8GBのメモリとCPUのみでも十分に実用レベルで動作させるための具体的な手法と設定が解説されています。クラウドAPIの利用コスト増大やデータプライバシーの懸念に対し、ローカル環境でのLLM活用が有力な選択肢となることを示しています。
著者は、Misskeyのローカルタイムラインを監視し、特定の投稿をLLMで分類してリアクションするBotを構築する事例を通じて、そのプロセスを詳細に説明しています。主なポイントは以下の通りです。
まず、メモリ使用量を削減するために不可欠な「量子化」の基礎知識として、Q4_K_Mなどの形式とそれぞれのメモリ目安が紹介され、8GBメモリでもQ4_K_MやQ8_0が動作可能であることが示唆されています。次に、ローカルLLMを動かすための主要ツールとしてOllamaとllama.cppを比較し、手軽なOllamaから試すことを推奨しています。
実運用で直面するであろう複数のハマりポイントとその解決策が具体的に提示されています。Ollamaのデフォルトコンテキスト長（2048トークン）が重いため、分類タスクなら512〜1024トークンに削減すべきであること、Qwen3モデルの「thinkingモード」が分類タスクには不要で、システムプロンプトやModelfile、あるいは最初からthinkingモードが無効化されたカスタムモデル（`hoangquan456/qwen3-nothink:4b`）を使うべきであること。また、ProxmoxなどのVM環境ではAVX命令がデフォルトで無効になっていることが処理速度を著しく低下させるため、CPUタイプを`host`に変更する必要があること。さらに、Ollamaがアイドル時にモデルをアンロードしてしまう問題に対しては、`OLLAMA_KEEP_ALIVE=-1`を設定して常駐化させる方法が解説されています。
実際のベンチマーク結果として、CPUのみの環境でも分類タスクは約2秒、コード生成では約12トークン/秒の速度が出ており、特に短い入出力タスクであれば実用レベルであることが示されています。最後に、Misskey監視Botの具体的なJavaScriptコードを提示し、プロンプトにFew-shot形式の例を入れる工夫やJSON抽出の安全策なども紹介しています。
この記事は、限られたリソース下でLLMを動かしたい web アプリケーションエンジニアにとって、実践的かつ具体的な解決策とノウハウを提供する価値の高い内容です。
6. AI時代のエンジニアの役割
「コーディングはAI任せ」でエンジニアは何をする？ AWSが示す、開発の新たな"主戦場"：AWS re:Invent 2025
https://www.itmedia.co.jp/enterprise/articles/2512/08/news047.html
AWS re:Invent 2025での発表に基づき、AIによる開発プロセスの進化と、エンジニアがAIエージェントを活用して「仕様駆動開発」へと役割を移行する未来を描き出す。
AWS re:Invent 2025の発表に基づき、本記事は生成AIによるコーディングの進化がエンジニアの役割と開発プロセスに劇的な変化をもたらしていると考察します。特に、ビジネス職とエンジニア職の境界が曖昧になる中で、AIエージェントを活用した開発が新たな「主戦場」になると強調されています。
AWSのエリン・クレーマー氏は、ビジネスサイドのユーザーがAIでプロトタイプを迅速に構築できるようになることで、エンジニアの役割が変化すると指摘。電通デジタルの山本覚氏も、高速なPoC開発が関係者間の認識合わせやコミュニケーション改善に極めて有効であると述べ、1人のエンジニアがAWSサービスを使い1週間で7つのプロトタイプを開発した事例を紹介しました。
AIが本番運用システム開発を完全に代替するわけではないものの、エンジニアの主戦場は「仕様駆動開発」（Spec-driven development）へと移行するとされています。エンジニアはシステムの仕様とアーキテクチャを定義し、エージェントが生成するコードやドキュメントを軌道修正しながら開発を進めます。AWSのIDE「Kiro」は、エージェントとの仕様書作成からコーディングまでを一貫して行う機能を備え、このプロセスを支援。クレーマー氏は、システムアーキテクチャに関する深い知識がAIへの効果的な指示出しに不可欠であり、経験豊富なシニアエンジニアが自律型エージェントの統率に特に適していると説明します。
AWS re:Invent 2025では、「Frontier agents」と称されるKiro Autonomous Agent、AWS Security Agent、AWS DevOps Agentなどの自律型AIエージェントサービス群が発表されました。これらのエージェントは、プルリクエスト学習、セキュリティ評価、問題の自律検知といった多岐にわたる開発タスクを自動化します。今後は少数のエンジニアがこれらのエージェントを多数統率し、コーディングだけでなく、複数の技術スタックに関する知識や開発プロセス全体のマネジメントがより強く求められるようになると予測されています。
AWS CEOのマット・ガーマン氏が掲げる「発明し続ける自由」を実現するためには、ビジネス職、エンジニア職、そしてAIエージェントの効果的な連携が鍵となります。エンジニアは、ビジネスが求めるプロトタイプを運用可能な形に洗練させ、セキュリティを確保し、AIエージェントを効果的に指揮する役割を担うこととなるでしょう。
AIはコードを書けるが、仕事は奪えない
https://terriblesoftware.org/2025/12/11/ai-can-write-your-code-it-cant-do-your-job/
AIはコードを書くタスクを代替するが、エンジニアの真の価値は判断力や問題解決といった非プログラミングスキルにあり、これこそがAI時代にエンジニアが生き残る道だと筆者は論じる。
筆者は、「プログラミングは死んだ」という論調に反し、AIはコード記述というタスクを代替できるが、ソフトウェアエンジニアの仕事全体を奪うものではないと主張します。この根拠として、OpenAIがAIコーディングアシスタント「Windsurf」（旧Codeium）に対し巨額の買収額を提示したこと、またAnthropicがJavaScriptランタイム「Bun」を開発チームごと買収した事例を挙げ、AIを開発する当事者である企業が、プログラミングスキルを持つエンジニアを依然として高く評価し、獲得しようとしている現状を指摘します。
エンジニアの真の仕事は、単にコードをタイプすることではなく、漠然とした問題を明確にし、コードベースの変更箇所を判断し、技術的負債を防ぐためのフィードバックを行い、本番環境でバグを見つけ、リリース判断を下すといった、多岐にわたる判断と文脈理解に基づく業務であると筆者は強調します。これは、電卓が計算を自動化しても、会計士の仕事が財務理解や顧客への助言といった判断力を伴う本質的な部分には影響しなかったのと同様の構図です。
AIによるレイオフの可能性を認めつつも、生き残るのはプログラミング以外の「判断力」「文脈理解」「構築すべきものを理解する能力」を持つエンジニアだと述べます。また、ジュニア開発者が判断力を養う機会が減るという懸念に対しては、AIが学習のフィードバックループを短縮し、より速く成長できる機会を提供すると、むしろ逆の可能性を示唆しています。
AI時代にエンジニアが価値を維持し、さらに高めるための具体的な行動として、以下の点を提案しています。
- AIツールを積極的に活用し、その真の価値と限界を理解する。
- 判断、トレードオフ、要件理解、ステークホルダーとのコミュニケーションといった非プログラミングスキルを磨く。
- 要件定義からデプロイ、保守まで、エンドツーエンドで物事を構築し、全体像を理解する。
- 書いたコードの量ではなく、解決した問題という形で自身のインパクトを記録する。
- AIを脅威として守るのではなく、マスターすべきツールとして好奇心を持って接する。
おわりに
今週の動向を振り返ると、AI開発エコシステムが「標準化」「品質管理」「現実的な評価」という3つの軸で成熟しつつあることが明確に見えてきます。
MCPとACPという二つのプロトコル標準化の動きは、特定ベンダーに依存しない持続可能なAI開発基盤の確立を目指すものであり、開発者が長期的な投資を行う上での安心材料となっています。GoogleやJetBrainsといった大手企業の参加は、この標準化の動きが一過性のトレンドではなく、業界全体の構造的変化であることを示しています。
AI時代のコード品質管理については、「スピードと品質はトレードオフではない」というGitHubの主張が象徴的です。CyberAgent、Ubie、エウレカといった国内企業の実践事例は、AIを活用しながらも、明確なルール、レビュープロセス、そして人間の判断を組み合わせることで、品質を担保しながら開発速度を向上させられることを実証しています。
一方で、AIの限界に対する冷静な認識も広がっています。ストールマンの「でたらめ生成器」という辛辣な批判、馬の事例に見る「突然の代替」への警告、そして「自信過剰な愚者」問題の提起は、AIを盲信することの危険性を示しています。しかし同時に、「AIはコードを書けるが、仕事は奪えない」という視点は、エンジニアの真の価値が判断力や問題解決能力にあることを再認識させてくれます。
コンテキストエンジニアリングと開発哲学に関する議論は、AI時代の開発がより高度な思考を要求することを示しています。OpenEvolveのようなアルゴリズム発見の自動化、中間表現を用いた品質安定化、チャット履歴のドキュメント資産化といった取り組みは、AIを単なる「コード生成ツール」としてではなく、開発プロセス全体を再設計するための触媒として捉える視点を提供しています。
実践事例とツール活用の章で紹介された、シャドウリポジトリ、LangGraphへの移行、低コストAWSパイプライン、8GBメモリでのローカルLLMといった具体的な実装は、AIツールを現実のプロダクション環境に適用する際の実践的な知恵を示しています。
最後に、エンジニアの役割に関する議論は、AI時代の開発者が「仕様駆動開発」へと主戦場を移し、AIエージェントを統率する役割を担うことを示唆しています。これは、コードを書く速度よりも、何を作るべきか、どう作るべきか、そしてそれをどう検証するかという、より高次の判断能力が求められることを意味します。
今週の動向が示すのは、AI技術の成熟と、それを使いこなすための組織的・技術的な知恵の蓄積が同時に進んでいる状況です。標準化された基盤の上で、品質を維持しながら、AIの限界を理解した上で活用する。このバランス感覚こそが、AI時代の開発者に求められる本質的なスキルであり、今週紹介された数多くの事例は、その実現可能性を具体的に示しています。
来週も、AI・コーディング領域の重要な動向をお届けします。
🤖 本記事は Claude Code を使用して編集されました。