[プラットフォームは、何を支えるのか] 第2部:AIで作れるものが増えたあと、プラットフォームは何を守るのか

第2部:AIで作れるものが増えたあと、プラットフォームは何を守るのか

本記事について
本記事に登場する企業、組織、人物、プロダクト、出来事はすべて架空です。公開されているPlatform EngineeringおよびSREの知見をもとに構成した思考実験であり、筆者が関わった特定の企業、案件、組織を説明・再現するものではありません。

前の文章 : 第1部:便利な社内ツールが、プラットフォームとして扱われるまで

プロダクトを作るハードルが下がった

Northstar Worksが標準的な開発経路を提供するようになってから、数年が経った。

その間に、ソフトウェア開発の環境は大きく変わった。

コーディング支援AIを使えば、これまで専門家へ依頼していた処理も短期間で実装できる。画面、API、データ処理、テスト、デプロイ設定のたたき台まで、AIが生成する。

各チームは、日常業務の課題を自分たちで解決し始めた。

問い合わせを分類するAI。
社内文書を検索するチャット。
定期レポートを生成するツール。
コードレビューを補助するAgent。
業務データを要約する小さなWebアプリケーション。

多くは小さな実験として始まった。

稟議や大規模なプロジェクトを待たずに試せる。価値がなければやめられる。課題を一番理解している人が、自分で解決策を形にできる。

それは、Northstar Worksが目指していたセルフサービスの発展形にも見えた。

しかし、作られるものが増えるにつれて、新しい問題が現れた。

作れることと、運用できることは同じではない

あるチームが、顧客から届く問い合わせを要約するAIツールを作った。

最初は、開発者が自分の作業を効率化するための実験だった。

やがて隣のチームも使い始めた。
その後、サポート部門にも共有された。
気づけば、毎日の業務で利用されるようになっていた。

ところが、ある日、そのツールが動かなくなった。

作成者は既に別のプロジェクトへ移っていた。
利用者は問い合わせ先を知らなかった。
どのモデルやデータへ依存しているのかも、十分には記録されていなかった。

別のチームでは、AI Agentが利用する権限が必要以上に広く設定されていた。

さらに別のツールでは、試験的に入力したデータがどこへ保存されるのか、利用者が把握していなかった。

一つひとつは善意から生まれた改善だった。

問題は、作成速度に対して、可視性、責任、セキュリティ、運用の仕組みが追いついていなかったことだった。

AIを構造化されていない形で導入すると、シャドーIT、ばらついた実装、セキュリティ上の弱点、スケール困難といった、Platform Engineeringが従来から扱ってきた問題が再び現れるという指摘がある。

「すべてを禁止しても解決しない」

経営会議では、AIツールの作成に事前承認を必要とする案も出た。

管理部門から見れば、自然な反応だった。

どこで何が動いているのか分からない。
誰がどのデータへアクセスしているのか分からない。
停止したときに誰が対応するのか分からない。

しかし、すべての試作に重い審査を求めれば、AIを使った小さな仮説検証は止まってしまう。

検証段階のツールと、正式に業務で利用するサービスを同じ基準で扱うことにも無理がある。

そこでNorthstar Worksは、禁止と放任の間に別の選択肢を作ろうと考えた。

AIプロダクトを一つずつ審査するのではなく、
安全に試し、安全に広げられる経路を提供する。

必要なのは、AIを使うたびに中央組織の許可を得る仕組みではない。

開発者が自律的に試せる余地を残しながら、コスト、セキュリティ、権限、データ利用などの最低限のルールを、共通の経路へ組み込むことだった。

二つの経路を用意する

Northstar Worksは、AIを利用した社内プロダクトについて、二つの経路を用意することにした。

これは製品の格付けではない。

現在の使われ方に応じて、利用者と提供者の期待値を揃えるための経路である。

実験の経路

個人または小さなチームが、価値を検証するために利用する。

• 限定された利用者だけがアクセスする
• 機密性の高いデータを扱わない
• 標準の隔離された実行環境を使う
• 一定期間後に継続要否を確認する
• 継続的なサポートや高い可用性は保証しない
• 利用者へ実験中であることを明示する

ここでは速さを優先する。

価値が分からない段階で、正式サービスと同じ運用体制は求めない。

提供の経路

複数の利用者が日常業務で使うものや、ほかのプロダクトが依存するものを対象にする。

• 責任を持つオーナーを決める
• 利用者と用途を把握する
• 扱うデータと必要な権限を確認する
• 標準のビルド・デプロイ経路を使う
• ログ、メトリクス、障害時の確認方法を用意する
• 変更方法とロールバック方法を決める
• 問い合わせ先を明示する
• 提供を終了する条件も決める

価値が確認されたプロダクトには、利用拡大に合わせて責任を追加する。

最初から完璧に作るのではなく、使われ方が変わったときに、通る経路を変える。

これは公開知見をもとにした本記事独自の設計例であり、特定の組織で採用された制度を示すものではない。

「Golden PathをAI Agentにも広げる」

従来の標準経路は、アプリケーションの作成、デプロイ、監視といった開発者の作業を支えていた。

AIを利用する場合は、それに新しい観点が加わる。

• 利用可能なモデル
• データの送信先
• プロンプトや設定の管理
• Agentへ与える権限
• 実行履歴と監査ログ
• 出力の評価方法
• 人間による確認が必要な操作
• 利用量とコスト

Northstar Worksは、モデルやAgentを自由に使わせる代わりに、標準のテンプレートと実行環境を提供した。

標準経路を利用すれば、必要なログ、権限制限、コスト記録、シークレット管理が自動的に適用される。

独自の方法を禁止するのではない。

ただし、標準から外れる場合は、チーム自身が追加のリスクと運用責任を引き受ける。

AIを利用するための仕組みも、個別に毎回作るのではなく、再利用できる形でプラットフォームへ組み込んでいった。

ガバナンスを会議ではなく、経路に埋め込む

すべての変更を人間が会議で確認すると、プロダクトの増加に追いつけない。

そこで、機械的に確認できるルールは実行経路へ組み込んだ。

例えば、

• 許可されていないデータ送信先を使っていないか
• 公開してはいけないシークレットが含まれていないか
• 最低限必要なログが有効か
• リソース上限が設定されているか
• 所有者情報が登録されているか
• 一定期間使われていない環境が残っていないか

を自動的に確認する。

ルールに違反してから注意するのではなく、安全な選択を最初から取りやすくする。

ガバナンスを開発後の審査として置くのではなく、開発者が通る経路の中へ組み込む。これによって、速度と安全性を対立させずに済む範囲が広がる。

ただし、すべてをコードで判断できるわけではない。

利用目的が妥当か。
出力の誤りが利用者へどの程度影響するか。
人間による確認をどこに置くか。
そもそもAIを使うべき課題なのか。

こうした判断には、プロダクト、法務、セキュリティ、業務担当者との対話が必要になる。

自動化するのは判断そのものではなく、明確に決められたルールを繰り返し確認する作業である。

何が存在するのかを見えるようにする

標準経路があっても、どのようなプロダクトが存在するのか分からなければ管理できない。

Northstar Worksは、正式に提供されるAIプロダクトについて、最低限の情報を一覧化した。

名称
目的
利用者
オーナー
利用するモデル・外部サービス
扱うデータの種類
問い合わせ先
稼働状況
最終確認日

目的は、中央組織がすべてを支配することではない。

利用者が問い合わせ先を見つけられること。
別のチームが似たものを重複して作る前に、既存の選択肢を見つけられること。
セキュリティやコストの問題が起きたとき、影響範囲を調べられること。

一覧を作ること自体が目的ではない。

必要なときに、組織が自分たちのプロダクトを認知できる状態を作ることが目的である。

作ったものを終わらせる経路も必要になる

AIによって試作が容易になると、使われなくなったプロダクトも増える。

実験環境が残り続ける。
利用者がいないのに、クラウド費用だけが発生する。
依存ライブラリやモデルが古くなり、脆弱性や互換性の問題を抱える。
誰も目的を説明できないサービスが存在する。

そこで、Northstar Worksは作成時に、見直し時期を設定することにした。

期限が来たら、次のいずれかを選ぶ。

• 実験を継続する
• 正式な提供経路へ移す
• 別のプロダクトへ統合する
• 停止して資産を削除する

新しいものを作れることと同じくらい、役割を終えたものを安全に閉じられることが重要だった。

停止ボタンを押すだけでは、終了したことにはならない。

データ、権限、シークレット、外部連携、監視、クラウドリソースなどを整理し、運用責任を明確に終了させるところまでを一つの経路として考えた。

自律性を奪わず、影響範囲を限定する

Northstar Worksが目指したのは、AIの利用を中央チームがすべて承認することではなかった。

各チームが自分たちの課題を解決できる自律性は残す。

その代わり、

• 標準的な安全策を簡単に利用できる
• 実験と正式提供の期待値を区別できる
• 重要なプロダクトには責任者がいる
• 何が存在するのかを把握できる
• 使われなくなったものを閉じられる

状態を作る。

AI Agentのように自律的に動く仕組みには、必要最小限の権限、実行結果の検証、操作履歴の記録、人間が介入できる仕組みが必要になる。

ガバナンスの目的は、すべての行動を止めることではない。

失敗が起きたときに、その影響が制御できる範囲へ収まるようにすることである。

作るための道から、育てるための道へ

Platform Engineeringの初期には、開発者がアプリケーションを作り、デプロイするまでの負担を減らすことが中心だった。

AIによって作成速度が上がると、それだけでは足りなくなる。

作ったあと、誰が持つのか。
どのようなデータを扱うのか。
どこまで安定性を期待してよいのか。
利用が増えたとき、何を追加で整えるのか。
使われなくなったとき、どう終了するのか。

プラットフォームは、作成を助ける場所から、プロダクトの変化を支える場所へ広がっていく。

必要なのは、すべてのAIプロダクトを同じ型へ押し込むことではない。

小さく試せること。
価値が見つかったら、安全に広げられること。
役割を終えたら、安全に閉じられること。

その三つを、開発者自身が選択できるようにする。

AI時代のGolden Pathは、
作るための一本道ではない。
試す道、広げる道、そして終わらせる道をつなぐものである。