【ITニュース解説】One Architect + Claude + MCP = A Full Engineering Squad: The Operating Model I'd Install at Your Company

システム開発の現場では、多くの時間と労力が「機械的な作業」に費やされている。例えば、決まったアーキテクチャ（システム全体の設計）に基づいてコードを書いたり、データベースとアプリケーション、画面表示の間に一貫性を持たせたり、誰もが納得するような基本的なデータ操作（データの作成、読み込み、更新、削除）のコードを書いたりする作業だ。これらは重要だが、高度な判断を必要としない定型的な作業が多く、実は開発チームの給与の大部分がそうした作業に充てられているのが現状だ。

しかし、この記事で紹介されている新しい開発モデルは、この状況を大きく変える可能性を秘めている。それは「一人のアーキテクト」と「AI（Claude Code）」、そしてAIが安全にシステムにアクセスするための「管理システム（MCPサーバー）」を組み合わせることで、従来のエンジニアリングチーム全体に匹敵する、あるいはそれ以上の生産性を実現するというものだ。このモデルは、AI時代における開発の新しいあり方を示している。

このモデルの核となるのは、三つの層で構成される仕組みだ。最も上の層には「アーキテクト」がいる。アーキテクトとは、システム全体の設計や方針を決める、いわば設計責任者だ。このモデルでは、アーキテクトが担うのは、システム間でやり取りするデータの形式や内容の約束事である「データ契約」の定義、セキュリティ上の信頼レベルが異なる部分の境界線である「信頼境界」の設定、そしてAIが生成したコードや設計の最終確認だ。つまり、高度な「判断力」と「意思決定」がアーキテクトの最も重要な役割となる。

真ん中の層には「Claude Code」というAIが位置する。ここでいうAIは、単なるチャットツールではない。それは、実際のコードリポジトリ（コードが保存されている場所）に直接アクセスし、コードを読み書き、修正できる強力なツールだ。このAIは「CLAUDE.md」という特別なファイルに従って動作する。このファイルは、システム全体のアーキテクチャ、コーディングのルールや慣習、AIが絶対にしてはいけない禁止事項、そしてコードの正しさを検証するためのコマンドなどを細かく定めた、いわばAIにとっての「憲法」のようなものだ。この憲法があるからこそ、AIは勝手な判断でシステムを破壊することなく、設計された意図通りに機能することができる。

そして最も下の層には「MCP（Managed Control Plane）サーバー」という管理システムがある。これは、AIが実際のシステムに安全に「手足」を伸ばすための仕組みだ。具体的には、データベースの構造やデータの型、関連性などを定義した設計図である「Postgres（データベースのスキーマ）」にアクセスしてデータを読み書きしたり、Webブラウザの動きを自動で制御し、画面の表示や操作を検証する「Playwright」を使って実際のユーザーインターフェース（UI）が正しく動作するかを確認したり、さらにはファイルシステムやGit（コードのバージョン管理システム）を通じて実際のコードベースにアクセスしたりする。MCPサーバーがあることで、AIは現実のシステムと連携し、単なるシミュレーションではなく、本物のデータとUIを扱って作業を進め、その結果を自己検証することまで可能になるのだ。

この三層構造により、どのような開発が可能になるのだろうか。例えば、アーキテクトが「注文APIに、ユーザーがスクロールするごとに新しいデータを読み込む『カーソルベースのページネーション』を追加し、そのAPIを使っているすべての画面や機能も更新せよ」という一つの指示を出したとする。すると、AIはMCPサーバーを通じてデータベースの実際のスキーマを読み込み、バックエンドのAPIコードを修正し、そのAPIを利用しているフロントエンドの画面のコードも更新し、さらにそれらが正しく機能するためのテストコードまで自動で生成する。そして、AIはPlaywrightを使って実際のWebブラウザでUIを検証し、変更が期待通りに動作していることを確認する。これら全ての作業が、一連の流れの中で、AIによって調整され、実行されるのだ。アーキテクトは最終的に、AIが生成した変更点を確認し、承認するだけで済む。

このモデルが置き換えるのは、前述したような「機械的な作業」の大部分だ。具体的には、システムの基本的な骨組み（足場）を作ったり、異なるシステム同士を連携させたり、コードや設定の一貫性を保ったり、定型的なテストコードを書いたり、データベースのバージョンアップに伴う移行作業を行ったりといった、時間のかかる面倒な作業だ。これらが自動化されることで、従来の開発チームの給与の大きな割合を占めていたこれらの作業コストが大幅に削減される。

しかし、このモデルがすべてを置き換えるわけではない。特に重要なのは「判断力」だ。システム全体のデータ設計である「スキーマ」をどうするか、どこまでが信頼できる情報で、どこからが外部の脅威となり得るかという「信頼境界」をどこに設定するか、そしてAIが生成したコードが本当に正しいのか、意図した通りに機能しているのかをレビューし判断する能力は、依然として人間にしかできない。むしろ、こうした「判断」ができる人材こそが、これからのAI時代に最も価値のあるエンジニアとなる。アーキテクトは、手作業が減る分、より高度な判断や意思決定に集中できるようになり、その影響力は劇的に増幅される。決断が下されれば、その日のうちにプロダクション環境（実際にユーザーが使うシステム）に反映されるため、意思決定から実現までの時間が大幅に短縮されるのだ。

この新しい開発モデルを会社に導入するための具体的な30日間の計画も示されている。最初の1週間は、まず各コードリポジトリ（コードの保管場所）ごとに「CLAUDE.md」というAIの憲法を作成する。これには、アーキテクチャの指針、コーディング規約、AIが避けるべきパターン、そしてAI自身が自分の作業を検証するためのコマンドなどを具体的に記述する。このファイルこそが、AIを「役立つ助手」にするか、「システムを破壊する存在」にするかの分かれ道となる。

次に2週目では、AIがシステムにアクセスするための「MCPサーバー」を実際のシステムに接続する。まずは、データベース（Postgres）に読み取り専用で接続し、次にデザインシステム（UIの部品やルールを定義したもの）、そしてWebブラウザへと段階的にアクセス権を広げていく。AIが実際のシステムにアクセスできることで、単なるコピー＆ペーストの情報のやり取りとは比較にならないほどの精度と効率で作業を進められるようになる。

3週目には、開発チームが普段最も面倒だと感じている定型作業、例えばデータベースの移行作業、足りないテストコードを埋める作業、システムの依存関係（他のソフトウェアとの連携）のバージョンアップ作業などを一つ選び、それをAIで最初から最後まで自動化してみる。これは、AIの能力を具体的に示す「概念実証」となり、チームにその効果を実感させるための重要なステップだ。

そして最後の4週目では、自動化された作業と、これまで手動で行っていた同じ作業との「サイクルタイム」（作業開始から完了までにかかる時間）を計測し、その結果をチーム全体に公開する。数値という明確な証拠を示すことで、AIによる自動化の導入は、上からの命令ではなく、その効果を理解したチームメンバーからの自発的な採用へとつながっていく。

この記事の筆者は、このモデルを自身のプロダクト開発で実践し、わずか12ヶ月で5つのプロダクトを単独で作り上げた実績を持つ。これは、AIが単なる技術トレンドではなく、実際のビジネスや開発プロセスを根底から変えうる強力なツールであること、そしてそれを最大限に活用するための「オペレーティングモデル」こそが、これからの成功を左右する鍵であることを示している。AIモデルそのものよりも、それをどう組織に組み込み、運用していくかという「 operating model 」が重要だという筆者の主張は、AI時代のシステム開発を考える上で非常に示唆に富んでいる。