【クラウドネイティブ会議】AI時代のプラットフォーム組織に求められる「境界を溶かす」エンジニアリング

AIエージェントの活用が広がるなか、企業の開発組織では「エージェントがどのリソースにアクセスできるのか」が重要な課題になっている。クラウドネイティブ会議でGitHub Staff Architectの服部佑樹氏は「境界を溶かすエンジニアリング――サイロを超える技術と文化のデザイン」と題してキーノートを行い、AI時代のプラットフォーム組織のあり方を解説した。AIを導入するだけでは十分ではなく、組織の境界や権限、会計・税務、コンテキスト設計といった課題に向き合う必要があると訴えた。

AI時代に問われるプラットフォーム組織の役割

GitHub Staff Architectの服部佑樹氏は冒頭、AIネイティブなプラットフォーム組織を考えるうえで「エージェントがどのようなリソースにアクセスできますか」という問いが重要になると切り出した。SRE関連のソリューションや各種ダッシュボードにもAI機能が組み込まれつつあり、コードベース、ドキュメント、チケット、運用情報などにAIがアクセスできれば、開発や運用の効率は大きく変わる可能性がある。

一方で、服部氏は「結局、やっぱり人に紐づいてしまう問題があるんです」と指摘した。AIエージェントが使えるリソースは、それを使う人間がアクセスできる範囲に左右される。人間がサイロの中に閉じ込められていれば、その人間が使うエージェントも同じサイロの中でしか動けない。

ここで服部氏は、プラットフォームエンジニアリングがこれまで取り組んできた課題を振り返った。無計画なツールやインフラの拡散、いわゆるスプロールを抑え、開発者の認知負荷を下げる。バラバラな仕組みを統一的なドメインモデルに集約し、開発者向けの内部プラットフォームであるIDPをプロダクトとして提供する。そして、開発者がセルフサービスで必要なリソースを利用できる状態を作る。こうした取り組みは、プラットフォームチームの基本的な役割として広がってきた。

プラットフォームとは開発者に必要なすべてがつまった場所であり、フィードバックを介して成長するエコシステム

ただし、服部氏は「作るべきものは愛されるプラットフォーム」であると強調した。プラットフォームは、チームが考えた「最強の仕組み」を開発者に押し付けるものではない。インフラ、APIサービス、テンプレート、ライブラリなどを含め、開発者とプラットフォームチーム、さらに開発者同士が有機的にやり取りできるエコシステムとして成長していくものだという。

AI時代には、この課題がさらに大きくなる。コーディングエージェントが普及し、開発チームの生産性が高まれば、プロダクト側の変更量やリクエストも増える。一方、プラットフォームチームの人数は同じようには増えない。AIの導入は、構造を変えなければプラットフォームチームの負荷を増幅させる可能性もあるのである。

人間のサイロは、エージェントのサイロでもある

次に服部氏は、ユーザーである開発者がどこにいるのかを問い「ユーザーはサイロの中に住んでいる」と表現した。企業の中には、社内組織、グループ企業、国外関連企業など、さまざまな境界が存在する。部署が違う、文化が違う、目的が違うといった言葉で説明されることも多いが、服部氏はこれを「境界のデザインの問題」だと捉える。

境界の背後には、アクセス権限、利益供与の懸念、会計上の判断基準、研究開発費と製品化の区分、輸出管理、移転価格税制など、具体的なビジネス上の理由がある。グローバル企業やグループ企業では、成果物の共有が利益供与とみなされたり、競争優位性のある成果物の共有が税務上のリスクになったりもする。

境界に何があるか

服部氏は前職での経験にも触れた。社内でGitHubリポジトリを作成する際には、それがライブラリなのか、SDKなのか、プラットフォームなのか、公開されるものなのか、社内用なのか、販売されるものなのかといった項目をフォームで整理するという。そのうえで、税務や国際的なコミュニケーション、パーミッションの処理が行われ、リポジトリが作成される。組織横断の開発を実現するには、技術基盤だけでなく、権限や会計、税務も含めた仕組みが必要になる。

ここで講演の中核となる言葉が示された。「人間の体験するサイロは、エージェントが体験するサイロです」。人間があるリポジトリやドキュメントにアクセスできなければ、その人間が使うエージェントもアクセスできない。すべてのリソースにアクセスできる特権的なエージェントを用意しても、それを使える人が限られれば、一部の人に負荷が集中するだけである。

そのため、服部氏は単にエージェントへ特権を与えるのではなく、組織そのものをパーミッションレスに近づけていく必要があると説いた。エージェントも人間も等しく必要な情報にアクセスでき、障壁やサイロを減らしていく。そのための一つの考え方として、講演ではInnerSourceが取り上げられた。

境界を溶かす戦略としてのInnerSourceとIDP

InnerSourceとは、単に社内でソースコードを共有することではない。服部氏は、オープンソースのプラクティスを社内に実装することだと説明した。オープンソースでは、利用者が課題を見つけ、改善に参加する。優先順位はボトムアップに形成され、セルフサービスで貢献が進む。ある程度の規模を持つチームがオープンソースのベストプラクティスを模倣するのは、こうした仕組みが効率的に機能するからである。

この考え方は、プラットフォームエンジニアリングにも接続する。IDPポータルは、開発者にとって入口をわかりやすくし、複雑な仕組みを隠蔽するうえで有効である。しかし、服部氏はIDPポータルへの過度な依存には注意を促した。ポータルで隠蔽すればするほど、裏側の複雑さや例外対応はプラットフォームチームに集中するからである。

IDPを提供する＝自律的な開発者エコシステムを作る

本来は、開発者が自分たちでPull Requestを送り、ブランチを作成し、他チームのPull Requestを確認できる状態が望ましい。メインブランチはブランチプロテクションで守りつつ、Write権限を持ったユーザーが改善に参加できるようにする。そうすれば、プラットフォームチームはゼロから要望を聞いて実装するのではなく、上がってきたPull Requestをレビューするところから始められる。

アクセスの壁に対する具体策として、服部氏はインターナルリポジトリの活用を挙げた。依存関係の高いライブラリ、ドキュメント、CI/CDテンプレート、AI関連リソース、エージェントスキル、AGENTS.mdのようなエージェント向け設定を共有することで、組織内の再利用とコラボレーションを促進できる。

さらに、GitHub Organization全員、正社員全員、正社員とContract全員といったチームを定義しておくことが重要だと語った。「勇気がいること」としながらも、Write権限をデフォルトにすることの意義も強調した。無制限に変更を許すのではなく、ブランチプロテクションで守りながら、貢献の入口を開くという考え方である。社内プロジェクトの利用条件を明示するインナーソースライセンスや、導入数、スター数などで活動を評価する制度も、境界を溶かす仕組みとして紹介された。

アクセス、会計・税務、コンテキストの壁を越える組織のエンジニアリング

講演後半で服部氏は、境界を溶かすための処方箋を三つに整理した。その三つとは「アクセスの壁」「お金と税金の壁」そして「コンテキストの壁」である。アクセスの壁はInnerSourceやリポジトリ設計、権限設計によって扱える。しかし、企業内外の共有を進めるうえでは、お金と税金の壁も避けて通れない。

服部氏は、プラットフォームチームが会計や税務を直接解決するチームではないとしながらも、ステークホルダーが多すぎるため誰も手を付けない問題になりがちだと指摘した。だからこそ、リーダーからのエンドースメントを得て、組織として整理していく必要があるという。

たとえば、ソースコードやサービスを他部門、他法人に共有する場合、無償提供は税務やコンプライアンス上の問題になり得る。そこで服部氏は、対価設計のテンプレートを用意することを提案した。対価は必ずしも金銭である必要はない。利用した側から動作確認やフィードバックを受け取ることも、貢献の証跡としての対価になり得る。国際的な協力では、競争優位性のある成果物と汎用的に共有できる部分を切り分ける設計も重要になる。

最後の壁が、エージェント時代のコンテキスト設計である。AIエージェントがPull Requestを作成するようになると、なぜその変更が必要なのか、どの前提に従うべきなのかがわからないという問題が起きる。そこで服部氏は、READMEやdocsディレクトリ、Issue、Pull Request上のやり取りを通じて、エージェントが参照できる文脈をリポジトリ内に整備する重要性を説いた。プロンプトにすべてを書き込むのではなく、人間とエージェントが同じ情報を参照できる環境を作るという考え方である。

講演のまとめとして、服部氏は、アクセス、会計、税務、コンテキストなど、さまざまなレイヤーにまたがる問題が存在するとしたうえで、解決策の鍵は「組織の構造をパーミッションレスにしていくこと」だと強調した。AIネイティブの時代には、開発者やビジネス担当者の背後にAIエージェントが存在する。だからこそ、プラットフォームもまた、エージェントを組み入れた貢献や、ユーザー同士の有機的なコミュニケーションを前提に設計する必要がある。

AI-Nativeなプラットフォームに進化させよう

ユーザーがセルフサービスで情報を参照し、問題を解決し、必要に応じてPull Requestなどの形で貢献できるようになれば、プラットフォームチームの負荷も下げられる。単にエージェントを組み込むだけでは、既存のサイロや権限の問題を増幅させるだけになりかねない。仕組み上の問題を解き、組織の境界を溶かしていくことによって、AIネイティブなプラットフォームチームへと成長できるというのが、服部氏のメッセージである。