← 기사 목록
日本語https://qiita.com/tags/ai/feed

AI時代のプラットフォームエンジニアリングを考えてみた

원문 사이트로 이동 ↗

추출된 키워드

29개
業務のデジタルツイン·5MCP·5ナレッジグラフ·5プラットフォームエンジニアリング·5Wiki·4shell-mcp·4GitHub Copilot·4Claude Code·4AIエージェント·4ガバナンス·3GitHub Copilot Business·3GitHub Copilot Enterprise·3Tool poisoning·3プロンプトインジェクション·3依存関係グラフ·3Single Source of Truth·3SSoT·3JIRA エピック·2Kafka·2Redis·2Cypher·2bastion·2踏み台サーバー·2GitOps·2VSCode·2Copilot CLI·2GitHub Actions·2EC2·1GCE·1

원문

14,511자
AI時代のプラットフォームエンジニアリングを考えてみた

概要

「AIで業務改善を進めたい」と意気込んでも、エンタープライズの現場ではなぜか進まない、ということがあります。ドキュメントは古い、AIに権限を渡すのは怖い、誰がAIに何をさせたかも追えない — このあたりが、組織にAIを降ろそうとする時に必ずぶつかる壁ではないかと感じています。

本稿では、こうした 3つの壁 を整理した上で、「業務のデジタルツイン」 という発想で乗り越える設計案を共有します。

断り書き:本記事は実運用で検証済みの設計ではなく、現時点で机上で組み立てた構成案です。部分的に個人で試してはいますが、組織導入は未検証です。また、AIクライアントとしてGitHub Copilot のみを導入している組織を想定して書いています。Claude Code など別のクライアントを併用している場合、特にガバナンス層の具体策は読み替えが必要になるかと思います。書き残しておくことで、自分自身の整理と、似た問題を考えている方との議論のきっかけになればと考えて公開しています。

本稿の前段となる記事を2つ挙げておきます。本稿は単体で読めるように書いていますので、未読のままでも問題ありません。背景の議論に興味がある方の参考までに。

はじめに - 3つの問題提起

AIが業務に入ってくる流れはもう止まらないと感じていますが、現場で実際に進めようとすると、3つの壁にぶつかります。

(1) AIによる業務改善は、実は難しい

業務改善はそれ自体がしんどい作業です。AIで大幅に効率化できるポテンシャルは感じるのですが、いざ進めようとすると、

  • 暗黙知が文章化されていない
  • ドキュメントはあっても古い、メンテされていない
  • 既存の業務フローを丸ごと作り直そうとすると、ハードルが高すぎて頓挫する

といった壁にぶつかります。「AIに置き換えるための業務量」のほうが、AIで削減される業務量を上回ってしまう、というやつです。既存業務フローを破壊しないで導入できるかがカギになると考えています。

(2) プロンプトと社内ドキュメントのメンテ

そもそも社内ドキュメントが整備されていない、というケースが多いように思います。

  • レガシープロダクトでドキュメントがない
  • あっても古すぎる
  • 業務知識が人の頭の中にしかない(ロストしているケースも)

ここに「AI用プロンプト」というレイヤーが乗ると、人間用とAI用で別々のドキュメントを二重メンテする状態になりがちです。メンテコストが2倍になり、片方が腐っていく未来が見えます。

(3) ガバナンス - AIによるCLI暴走のリスク

個人的にはここが一番怖いと感じています。

  • 個人PCの GitHub Copilot が暴走して、CLIで 
    ssh
    を叩き、本番環境を荒らす
  • 個人ローカルの権限でAIが好き勝手にコマンドを叩くと、組織として追跡不能
  • プロンプトインジェクション(AIへの指示を悪意ある文章で上書きされる攻撃)やTool poisoning(野良MCPツール、あるいは一見良性に見えても description に悪意ある指示が埋め込まれた MCP ツールが紛れ込んで、AIに有害コマンドを実行させる攻撃)で意図しない操作が走る

「AIが何をしたか組織として追えない」「誰が何の権限でAIに何をさせたか分からない」状態は、エンタープライズだとそもそも導入のテーブルにすら載らない、というのが現実かと思います。

概要

主張はシンプルにまとめると2点です。

  • 業務を"地図"にする— 社内アプリ・DB・ログの依存関係グラフとWikiの手順書を組み合わせて、AIが読める**"業務のデジタルツイン"**を作る
  • AIに"首輪"をつける— MCP(AIに外部ツールを使わせる標準プロトコル)を中央集権的に管理し、本番への危ない経路だけ塞ぐ

材料は 依存関係グラフ + Wiki + Shell MCP の3つだけです。新規SaaS導入はゼロ、既存Wikiも壊さない。明日からWiki 1ページの追記で始められる構成を狙っています。

解決策

全体像はこのようになります。

3つの柱 — Wiki / ナレッジグラフ / Shell MCP — を順番に見ていきます。

Wiki: プロンプトとの一体化

詳しくは 前回記事 で扱ったので、ここでは要点だけ書きます。

  • 社内Wikiの同じページに、人間用のbashコマンドと、AI用のMCPリンクを併記する
  • そのWikiが、組織として使ってよいMCPのホワイトリストを兼ねる
  • 既存Wikiの階層構造はそのまま、ページに数行追記するだけで運用に乗る
## prod デプロイ手順

### 人間がやる場合
gh workflow run deploy.yml -f env=prod

### AIに任せる場合
[Deploy用MCP](https://github.com/cacapouh/wiki/tree/main/mcps/deploy-mcp.md) を使って prod に deploy する

これだけで、人間用とAI用の手順書がひとつの SSoT(Single Source of Truth = 情報の唯一の正) にまとまります。二重メンテ問題が消える見込みです。
加えて、野良MCPはWikiに載っていないので使えない = Tool poisoning も同時にブロックできる構造になります。

補足:GitOps がちゃんと回っている組織なら、手順自体がコード化されているので、この仕掛けはそもそも不要かもしれません。本稿で想定しているのは「Wikiに業務手順が散らばっている」普通の組織です。

ナレッジグラフ: 業務のデジタルツイン

ざっくり言うと、「アプリの依存関係マップ」をAIに渡す話です。

社内業務でグラフ化する対象は色々ありますが、プラットフォームエンジニアリング観点では、まず アプリケーション・ログ・DB間の依存関係 を入れるのが安牌かと考えています。これだけでも十分強力に効くはずです。

例えば、こんなつながりです。

各ノードはプロパティとしてWikiリンク(リポジトリ、デプロイ手順、E2E手順、Kafkaトピックの JSON スキーマ、Redis のメンテ手順 など)を持ちます。ノードと辺だけでなく、各ノードに紐づくドキュメントへのリンクが、AIが業務を辿る時の足場になる、という発想です。

AIがどう読むか

MCPで「指定ノードから辿る」「逆向きに依存元を列挙する」だけのインターフェースをグラフに生やしておけば十分だと考えています。Cypher相当の表現力は要りません。

例えば、ユーザーから次のようなプロンプトが来た場面を想定してみます。

「api-app-a を1時間メンテで止めたい。影響範囲とオンコールチームを出して」

このとき、AIエージェントの推論ステップは、概ね次のように進む想定です。

  • プロンプトから対象ノード 
    api-app-a
    を特定
  • グラフ検索MCPで 
    api-app-a
    の下流を辿り、
    topic-a
    (KafkaTopic) を取得
  • さらに 
    topic-a
    の下流を辿り、
    stream-processor-b
    を取得
  • 同様に進めて 
    redis-cluster-c
    まで到達
  • 各ノードのプロパティから、オンコールチームとランブックのWikiリンクを収集
  • 集めた情報を要約してユーザーに返答

ポイントは、この一連の推論ステップが「グラフを辿る操作」だけで構成されている ことです。すると、2つの強みが立ち上がります。

  • 説明可能性: AIに「どう辿った?」と後から聞けば、グラフ上のパスとして人間が追える形で説明させられます。推論経路がグラフという構造化された形で表現できるからこそ、ブラックボックスにならずに済む、という発想です(必要なら、MCP側でアクセスログを取って残すことも可能です)。新メンバーがAIの動きを理解する助けにもなります
  • 予測可能性: グラフを見れば、AIがどう推論を進めるかを事前にある程度想像できます。挙動を制御可能な範囲に収めやすく、エンタープライズ導入時に重要となる「AIのブラックボックス化を避ける」という観点でも効きます

従来は「詳しい人に聞き回る」しかなかった作業が、グラフを辿るだけで説明可能な形で完結する 想定です。

もう一歩踏み込んだ使い方: JIRA エピックの並行開発

もう少し生き生きとした使い方も想定してみます。

新機能の開発で、複数のタスクやストーリーをまとめた JIRA エピック(複数タスクを一つのジャンルでグループ化したもの)が切られ、その中身が 複数アプリにまたがる改修 だった、という場面はよくあるかと思います。例えば「イベント処理基盤の刷新」エピックの配下に、

api-app-a
、
stream-processor-b
、
redis-cluster-c
の3アプリに渡る改修タスクが並んでいる、といったケースです。

従来であれば、こういう作業は概ねこんな流れになりがちでした。

  • アプリ間の連携仕様を、有識者に聞いて回る
  • 前段処理を改修した時に、後続に何が起きるかをコードとドキュメントから手で追う
  • 3つのコンポーネントを順に検証環境へデプロイ。手順書はそれぞれ別のWikiページ
  • 全部つながったところで、ようやくサービス全体のプロトタイプが動かせる

ナレッジグラフが整備されていれば、この一連の流れを AIエージェントに任せる経路 が見えてきます。各ノードのプロパティに 

deploy_guide
や 
e2e_guide
の Wiki リンクを持たせておけば、AI は次のように動かせる想定です。
  • エピックから関係ノードを特定— 改修対象を起点に、グラフを辿って関係する Kafka トピック・後続のストリーム処理・書き込み先の Redis などを列挙
  • 影響範囲を出す— 「
    api-app-a
    のログフォーマット変更が
    topic-a
    の JSONスキーマに影響し、さらに
    stream-processor-b
    の入力パースに伝播する」といった変更影響を、依存辺から自動抽出
  • 検証環境へ一斉デプロイ— 各ノードに紐づいた「検証環境デプロイ手順書」Wiki リンクを順に開き、ページ内の MCP リンクを叩いてデプロイ
  • プロトタイプ動作確認— 全部つながった状態で、各ノードの
    e2e_guide
    を辿りつつ、サービス全体のE2Eをエージェント主導で走らせる

ここで効いているのは、グラフのプロパティに Wiki リンクを持たせる という素朴な仕掛けです。グラフ自体はノードと辺だけでよく、「どうデプロイするか」「どう動かすか」の手順は Wiki に任せる。AIはグラフを辿って手順書に到達し、手順書から MCP に到達して実行する。「グラフ → Wiki → MCP」の3段の辿り が、ここまでの3つの柱を貫いて動く構造です。

検証環境でのプロトタイプ動作確認まで自動で回るようになれば、エピック単位の開発リードタイムを大きく削れる可能性があります。他にも、障害時の波及推定や関係オンコールチームの即時列挙など、グラフが効くシーンは色々と見込めます。

ここから先の広がり

ここまではアプリ間の依存関係を中心に話してきましたが、本来ナレッジグラフはもっと多様な対象を表現できます。ここから先の広がりについて、可能性だけ触れておきます。

例えば、開発チームをノードとして扱う ケースを考えてみます。

この一辺があるだけで、「ストリーム処理Bに不具合がありそうだ」と気付いた人(人間でもAIでも)が、どのチームに連絡すればいいかを即座に逆引きできる 状態になります。Slackチャネルやオンコールローテーションへのリンクをチームノードのプロパティに乗せておけば、連絡経路まで含めて自動化できる見込みです。

同じ発想で拡張できる対象は色々と考えられます。

  • 過去の障害イベントをノードとして残し、関連コンポーネントに辺を張る — 「このトピック、過去にトラブった?」が辿れる
  • ノードに コストプロパティを持たせる — Redisクラスタの月額やKafkaの保持容量から、棚卸し対象を機械的に拾える

ただし、最初からこれを全部やる必要はないと考えています。アプリ・ログ・DBの依存関係に絞って始め、効果を見ながらノード種別を増やしていく、というのが現実的な進め方かと思います。グラフの強みは 「後から辺やプロパティを足しても既存利用が壊れない」 ところで、これは始めるハードルの低さと表裏一体です。

ガバナンス: MCPを中央集権的に制御

ガバナンスは大きく2層で考えています。接続できる MCP を組織で絞る(リモートMCPの許可リスト)と、シェル実行の経路を縛る(shell-mcp による経路ポリシー)です。

リモートMCPは組織で承認したものだけに

まず、AIクライアントが接続できる MCP サーバー自体を、組織で承認したものに限定します。Wikiセクションで「Wikiに載っているMCP = 組織のホワイトリスト」を提案しましたが、これをAIクライアント側でも強制する仕組みです。GitHub Copilot Enterprise / Business では、Configure MCP server access を使って、組織として登録した MCP レジストリのサーバー以外への接続をブロックできます(

Registry only
ポリシー)。

これで、Wikiに載っていない野良MCPや、ドキュメント外で得た MCP 接続情報を勝手に使ってしまうリスクを抑えられます。

シェル実行は shell-mcp で経路を縛る

許可された MCP の中でも、特にシェル実行は危険なので別建てで対策します。ここで使うのが shell-mcp です(MCPサーバー越しにシェル実行を許可しつつ、宛先や経路をポリシーで縛る、というコンセプトを実装してみたものです)。詳しくは README に書いていますが、ポリシーの骨子は1行で表現できます。

悪いことをしようとしない限り、本番環境が壊れたり、外部リークしたりしないようにする。ただし現実的な運用が成立する範囲で。

「ガチガチ」と「ザル」の間を、現実的な落とし所として狙う方針です。これをAIクライアント別に具体化します。

補足: GitHub Copilot の MCP allowlist の限界と、Claude Code の優位性

前述のとおり、GitHub Copilot の MCP allowlist は ID/Name マッチングのみで動きます。これが実運用で何を意味するかというと、stdio 型 MCP の多くは

command: "docker run ..."
で起動されるため、allowlist で
docker
を許可した瞬間に、docker で起動できるあらゆる MCP が事実上通ってしまう、という構造的なガバガバ問題に行き着きます。

一方、Claude Code には

や
managed-settings.json
managed-mcp.json
といったMCP サーバー単位の組織ポリシー機構が専用に用意されており、許可リスト方式で「managed が許可した MCP 以外は起動不可」が組める仕組みになっています。managed scope は user / project / CLIフラグのいずれからも override 不可能で、組織ポリシーとして堅く効きます。

本稿は GitHub Copilot 前提で書き始めたのですが、調べていく過程で、

現時点で本気で組織的なガバナンスを効かせるなら、Claude Code を主軸に据える方が向いていると感じています。shell-mcp 自体は「本番経路の遮断」という別軸の役割で、いずれのクライアントでも有効です。

GitHub Copilot の場合

  • VSCode: 組織的にを
    chat.tools.terminal.enableAutoApprove
    off
    • これで AI による自動ターミナル実行をブロックできます
  • Copilot CLI(: 組織ポリシーで丸ごと OFF
    copilot
    コマンド)からのAI実行系
    • 個別の細粒度制御(シェル実行だけ縛る、autopilot だけ禁止 等)はポリシーとして提供されていない印象です(2026年5月時点。詳しい方がいらしたら教えていただけるとありがたいです)
  • 代わりにshell-mcp経由でシェル実行を許可し、踏み台への ssh をブロック

経路の線引き

具体的な線引きはインフラ構成次第ですが、一番イメージしやすいオンプレ中心の組織を例に書いておきます。

オンプレでは、本番への到達経路がだいたい 踏み台サーバー(bastion) 1点に集約されているかと思います。AIエージェントが本番に何か悪さをしようとすれば、たいていは踏み台への ssh が最初のステップになるはずです。

逆に言うと、shell-mcp で 踏み台への ssh だけブロック してしまえば、その先の本番ホスト群に AI が辿り着く経路は事実上塞がる想定です。開発者ローカルや検証環境の host への ssh はそのまま素通しにすれば、AIエージェントの実用性は十分に確保できるはずです。

クラウド寄りの構成については筆者の経験が薄いので深くは踏み込みませんが、「本番への到達経路のチョークポイントを特定して、そこだけ shell-mcp でブロックする」という考え方自体は応用が効くのではないかと思います。

なお、ここでの線引きはあくまで shell-mcp が制御する直接的なシェル経路 の話です。Wiki に承認済みとして登録された業務MCP(例: 

github/deploy
が GitHub Actions を起動してデプロイする、
catalog/impact
が依存関係グラフを参照する 等)経由でのリモート実行は別軸で扱います。業務MCP は API として整備された安全な抽象を経由するため、結果として本番に作用するもの(deploy 系など)も含めて、Wiki に載っている限り許可 という想定です。あくまで「直接シェルを叩いて本番に到達する経路」だけを shell-mcp で塞ぐ、という整理になります。
実行先可否理由
開発者ローカルOKサンドボックス的扱い
検証環境の host / コンテナOK落としても影響が局所的
踏み台サーバー(bastion) NG 本番への横移動が容易
クラウド環境の本番 host(EC2/GCE等) NG 認証情報・本番データに到達可能

要するに「本番アクセス経路は禁止、それ以外は shell-mcp で実用性を確保」という線引きを、自組織のインフラ構成に当てはめる作業になります。

こうして見ると、本稿の3つ — (1) AI による直接シェル実行を組織的に禁止、(2) MCP allowlist、(3) shell-mcp に禁止ホストを焼き込み — は 多層防御 として組み合わせて初めて効く構造です。allowlist が ID マッチングだけで bypass されても、(1) で AI 自体が直接シェルを叩けないため、結果として本番経路は塞がる、という発想です。これが「ガチガチ過ぎない」現実的な落とし所だと考えています。

なぜこの布陣が効くと考えているか

3つの柱を組み合わせると、デジタルツインの世界観が成立する想定です。

  • Wikiが業務の手順を写す → 人間とAIで同じ手順書を共有
  • ナレッジグラフが業務の構造を写す → AIに"地図"を渡す
  • MCP集約 + CLI禁止 + shell-mcpが AIエージェントの動ける範囲を縛る → ガバナンスと実用性を両立

シミュレート可能な世界として組織業務のデジタルツインが立ち上がり、その上をガバナンス済みのAIエージェントが走る、という絵を狙っています。

構成自体は既存資産の組み合わせで、大きな新規導入は要りません。

  • 既存Wikiの階層構造を壊さない— ページに数行追記するだけで始まる
  • グラフ + Wiki + Shell MCPだけで完結。新規SaaS導入はほぼゼロ
  • 1業務分のミニデジタルツインから積み上げられる

明日からひとつのページに数行足すだけで、布陣の構築が始められる想定です。既存業務フローを破壊しないで導入できる、これが現場目線で一番効くポイントではないかと考えています。

まとめ

AI時代のプラットフォームエンジニアリングは、社内業務のデジタルツインを作る営みとして捉え直せるのではないか、というのが本稿の主張でした。

  • Wikiで人間とAIの手順を一体化(SSoT化)
  • ナレッジグラフで業務の依存関係を構造化 = デジタルツイン
  • MCP中央集権 + CLI禁止 + shell-mcp(本番host除く)で AIエージェントを縛る

大規模なツール導入も組織変更も必要なく、来週からでもWikiの1ページから着手できる構成として、ひとつの選択肢になればと考えています。