できる人ほど教える時間がない AIは暗黙知の夢を見るか

仕事ができる人ほど、教える時間がない。ベテランが無意識にこなす判断や段取りは、言葉にされないまま特定の個人にとどまる。この暗黙知を、AIは組織の資産に変えられるのか。CTCが導入企業で示したのは、AIツールを足すのとは別の答えだった。

[平 行男，キーマンズネット]

　システム開発・運用の現場では、専門的な知見を持つ人材ほど仕事が集まりやすい。だが、できる人ほど日々の対応に追われ、その知見をドキュメントやOJT（On-the-Job Training）で後進に渡す時間を確保できない。結果として負荷は一部のメンバーに偏り、対応のスピードと品質が特定の個人に依存する。ITツールを一つ増やたとしても、現場運用の「ラストワンマイル」に残るこの属人化は崩れない。

　この壁を崩すには、作業の過程に埋もれた知見を記録し、誰もが再利用できる形に変える必要がある。その方法を、伊藤忠テクノソリューションズ（CTC）の田中久智氏（StageCrew Co-Creator & Product Manager）が、同社のプラットフォーム「StageCrew」を軸に語った。

　導入企業では、初動対応や原因特定・問題解決に要する時間が大きく変わったという。ただし、数値を生んだのはAIの導入そのものではない。現場の何を記録し、どう運用へ戻したのか。

「マニュアルを作ったら終わり」を超える知見運用へ

伊藤忠テクノソリューションズの田中久智氏（撮影：筆者）

　田中氏はStageCrewを「AI時代の知見運用プラットフォーム」と定義する。前提にあるのは、AIの活用によって業務の進め方や、現場で必要とされる知見が絶えず変化するという認識だ。

　「AIのツールによって仕事が効率化されている現代、皆さんの仕事の仕方、個の知見は変わり続ける時代に入ったということです」

　変化を前提にすると、一度作った文書を保管するだけのナレッジ管理では追い付きにくい。同社が掲げる「Fluid Knowledge Transformation Platform」というコンセプトは、変化する現場のノウハウをAIで取り込み、組織で再利用し、自動化につなげる仕組みを指す。

　設計思想の軸は人間中心（Human-centric）だ。特定のツールやデータ環境に閉じず、異なるツールやWebサイトを横断して利用する。「ツールやサービスに縛られずに、人の知見そのものを資産化して、組織の持続的成長を支える」と田中氏は説明する。

　中核を成すのが2つのAIエンジンだ。仕事の記録を文書に変える「AI駆動ドキュメンテーション」と、AIおよびブラウザエージェントが情報収集・分析を支援する「AI駆動分析」となる。

StageCrewが備える2つのAIエンジン（講演時の投影資料から）

有事の「調べる」を待たない

　講演では、AI駆動分析の設定画面が示された。画面構成は起動タイミングと収集対象、通知先の3つ。アラート受信時や毎朝何時といったトリガーで、自社のWebサイトや監視ツール、クラウドのステータスサイトを巡回させ、結果をメールや「Slack」「Teams」へ届ける。

　収集の指示は自然言語で書ける。Webにアクセスできるか、ログイン画面が表示されるか、一部のAPIがエラーになっていないかなど、確認したい観点をプロンプトで表現しておけば、ブラウザエージェントが情報を集めに行く。1週間前や2週間前のデータも同時に取得するため、差分からの絞り込みまで自動化される。

　実行すると数分で結果が届く。デモで示された出力結果は、一部でログインが進まず、その裏では500系のエラーとトラフィックのスパイクが見えている、という内容だった。「一から情報を集めなければ状況をつかめず、特定の担当者がいなければ何が起きているのかも分からない、という前提が変わる」と田中氏は説明する。分析の根拠となった元データも確認でき、最終判断は人が下す。

　用途はインシデント対応にとどまらない。各社のクラウドのステータスサイトを定期巡回し、自社や顧客がどのクラウドを使っているかというマッピングデータと突き合わせれば、特定リージョンの障害が自社に影響するかを素早く絞り込める。クラウドサービスなどの利用規約の差分チェックにも同じ仕組みを使えるという。

AI駆動分析の設定画面（講演時のデモ画面から）

ベテランの「無意識の判断」まで文章にする

　もう1つのエンジンである、AI駆動ドキュメンテーションのデモでは、Google Cloudで検知したログインエラー多発のアラートへの対応が題材となった。担当者が画面を操作しながら調査を進める様子を、StageCrewがそのまま録画する。

　調査自体もAIが支援する。「Geminiで調査」を実行すると、数十秒でアクセス元のIPアドレスやログインに失敗したアカウント情報が抽出された。担当者は外部サイトでもIPアドレスを照会し、クラウドセキュリティプロキシ経由の企業ドメイン内の通信だと確認して問題なしと判断した。この調査の過程が、そのまま文書化の素材になる。

　文書を生成する際は、保存先のフォルダや言語、AIモデル、文書タイプを選ぶ。デモではGeminiを指定し、日本語で作成した。

　同じ録画から、性質の異なる3種類の文書が出力された。1つ目は、他のメンバーが読んでそのまま実行できる、作業手順書。2つ目は、何を対象にどう調査し、何をもって問題なしと判断したかを記した、事実ベースの調査報告書。3つ目はナレッジ発掘レポート。作業に潜む、経験者だからこそ取る所作を抽出する文書だ。「別のサイトへクロスチェックに行く」「クエリを書いて探すのではなくAIを使う」、こうした暗黙の判断が、文章として表現されていた。

　この機能の活用シーンはデジタル業務に限らない。デモでは、オフィス内のテレワークブースを定期巡回して点検する動画から、音声を含めたマニュアルがすぐに生成された例が示された。

録画から生成されたナレッジ発掘レポート（講演時の投影資料から）

導入企業で初動70％、原因特定・解決85％短縮

　では、効果はどの程度か。

　田中氏はCTCの自社調べとして、導入企業での実測値を示した。AI駆動分析では、初動対応を70％迅速化し、根本原因の特定や問題解決に要する時間を85％短縮したという。障害発生時の影響範囲の把握と一次切り分けを支援する他、IPアドレスやネットワーク構成の変更、クラウド障害、EOS（提供終了）、脆弱（ぜいじゃく）性などを継続的に追跡し、「調べる」時間を減らすとしている。

　AI駆動ドキュメンテーションでは、マニュアル作成時間を30〜50％、説明や共有、引き継ぎの時間を30〜90％削減し、新メンバーの立ち上がり期間を3分の1に短縮したという。

　田中氏は、こうした削減効果を支えるのは、文書を短時間で作成し、業務の変化に合わせて更新できる仕組みだと説明する。手順が変われば、新しい作業を録画して文書を作り直す。事象が起きた時点で調査過程を文書化できれば、同じことを何度も調べ直したり、口頭で伝え直したりする作業を減らせる。

　その上で田中氏はROIを構成する3つの柱を提示した。限られた人しか対応できなかった仕事の平準化と、AIとの役割分担による「省力化」。熟練者を反復作業から解放し、余力を次の価値へ再投資する「余力創出」。そしてチェック作業を自動化し、個人頼りや手作業を防ぐ「リスク回避」だ。

　ただし、実際に効果が出るかどうかは、土台となる知見をどう運用するかで決まると田中氏は言う。投資すべき対象はAIツールだけではない。現場の暗黙知を構造化し、組織の誰もが活用できる状態を保つ運用も含まれる。

Whatで止めない　HowとWhyに踏み込む

　CTCは、知見を、事象や事実を共有・報告する「What」、やり方を伝える「How」、理由や背景を残す「Why」の3層に整理する。作業を記録して文書化するだけでは、Whatで止まりやすい。そこで同社は、“Howの自動化”と“Whyの深掘り”を進めている。

　1つ目はHowの自動化だ。「ナレッジが構築されるのは重要な一歩ですが、毎回人が対応することはゴールではない」と田中氏は言う。Howの自動化を担うのが「Automation Bridge」だ。AI駆動ドキュメンテーションが構造化した仕事の記録を基に、自動化の方法を提案する。StageCrew内のシナリオに限らず、AIエージェントやRPAなど外部の仕組みにもつなぎ、記録した手順を実行へ移す狙いがある。

　Whyの深掘りでは、判断の理由や背景を言葉にする必要がある。田中氏は、KikuviのAIヒアリングエージェントとの連携を紹介した。StageCrewが仕事の記録からナレッジを抽出し、経験者にしか分からない部分をKikuviが本人への質問で掘り下げる。これにより、作業記録だけでは残りにくい判断の理由を補う。

　蓄えた知見の活用先として示されたのが、「Gemini Notebook」（旧NotebookLM）との組み合わせだ。個人やチームでは知見を対話的に引き出し、部門では文書を説明資料や動画に変換する。さらに組織全体へ展開し、教育や業務支援に使う構想だ。

「支援する人」ではなく「推進しきる人」を最前線に

　仕組みを用意しても、誰が現場で使い、改善を進めるのかという課題は残る。そこでCTCが位置付けるのが、FDE（Forward Deployed Engineer、フォワード・デプロイド・エンジニア）だ。事業の最前線に入り、技術を実装して成果につなげるエンジニアを指す。

　CTCが対比した従来型の支援は、システムの導入や引き渡し、伴走が中心だった。これに対してFDEは、成果が出るまで現場を前に進める。「支援する人ではなく、推進しきる人」と田中氏は表現する。ただし、成果を個人の力量だけに頼れば、新たな属人化を生む。課題の発見と実装、推進を組織として回す仕組みが必要になる。

　StageCrewはFDEを支えるため、作業の文書化や属人業務の可視化、標準手順の自動化、暗黙知の掘り下げ、必要な知見の提示、組織への横展開という一連の流れを担う。重要なのはAI製品を導入することだけではなく、現場の作業を誰が記録し、更新し、自動化の対象を判断するかという運用設計だ。

FDEに装備させるStageCrewの機能（講演時の投影資料から）

　田中氏は、最終的なゴールを「お客さま自身が成果を出し続けられる状態」と説明した。個人の知見を記録して共有するだけでなく、更新と自動化まで回し続けられるか。講演で示された実測値は、AIの効果を測る際に、ツールの利用率だけでなく、現場の調査や文書化、引き継ぎに要する時間を見る必要があることも示している。

※本稿は、2026年7月30〜31日に開催された「Google Cloud Next Tokyo」（主催：グーグル・クラウド・ジャパン）の講演「事例が示す AI 活用 ROI がここに！FDE × AI で拓く対応高度化最前線」の内容を基に、編集部で再構成した。