AWS Machine Learning Blog が公開した、パナソニック アビオニクス (Panasonic Avionics) の機内エンターテインメント・通信システム (IFEC) 診断に AI エージェントを組み込んだ事例を読んだ。AI エージェントを業務に導入したい会社が、どこまで自律性を与え、どこで人間を挟むかを判断するための材料として整理する。
要点 (出典の事実のみ)
- パナソニック アビオニクスが AWS および AWS Generative AI Innovation Center と共同で、IFEC の障害診断を行うマルチエージェント構成を構築した。数千通りの機材構成にまたがる診断が課題だった。
- 構成は3層。フリート全体の KPI から異常を検知する Trend Analyzer、並列に走る診断エージェント (Correlation Analyzer / System Checks / Log Analyzer)、そして所見を診断レポートにまとめる LLM Summarizer (Amazon Bedrock 上の Claude)。
- 基盤は Amazon Bedrock、Amazon SageMaker (LangGraph によるオーケストレーション)、AWS Glue / Amazon EMR、S3 + Apache Iceberg のレイクハウス、Amazon RDS + pgvector による過去インシデントの類似検索。エージェント実装には Strands Agents SDK と LangGraph を利用。
- AI の推奨は運用データと過去インシデントでグラウンディングし、決定的なビジネスルールで検証する。運用上重要なインシデントの是正措置は人間のエンジニアがレビューして承認する。エージェントの判断と推奨には追跡性 (auditability) を持たせている。
- 効果は「対象を絞ったユースケースで運用効率 20〜40% 改善」「数時間の手作業レビューが数分の自動分析に短縮」。精度は正解データとの突き合わせで「要求水準を安定して上回った」とあるが、具体的な精度値は公開されていない。記事には「実際の結果はデータ特性・運用文脈・システム構成により変わりうる」との但し書きがある。
徐 聖博の見解
この事例で一番参考になるのは、モデルでもフレームワークでもなく、自律性の配り方だと私は考えている。
単一の万能エージェントに「障害を診断して直せ」と投げるのではなく、異常検知・相関分析・構成チェック・ログ照合という元々人間がやっていた分業をそのままエージェントの境界にしている。そのうえで、出力は決定的ルールで検証し、重要な是正には人間の承認を挟み、判断の経路を追跡できる形で残す。これは AI の話というより、監査が入る業務システムの設計作法そのものだ。航空機の保守という、間違いのコストが高くログが構造的に残っている領域だからこそ、この作法が最初に効いている。
受託開発と AI エージェント事業の両方をやっている立場で見ると、この構成は「AI を入れる前にやることがある」という現実を突きつけてくる。前提として、Iceberg のレイクハウスに集約された運用ログと、過去インシデントをベクトル検索できる状態があって初めて、エージェントは「勘」ではなく根拠で答えられる。エージェント導入プロジェクトの工数の多くは、実際にはデータ側とルール側に落ちる。
AIエージェントはどのような業務で効くのか
出典の事例が示す条件は明快だ。(1) 判断材料がログ・メトリクス・チケットとしてすでにデジタルで残っている、(2) 熟練者の暗黙知に依存していて属人化している、(3) 同種の調査が繰り返し発生する。この3つが揃う業務——障害一次切り分け、問い合わせの原因調査、大量の構成差分の突合——は、現時点で最も投資対効果が読める領域である。逆に、判断材料が人の頭と電話の中にしかない業務は、エージェント以前にデータ化が先になる。
AIエージェントの欠点・限界をどう扱うか
出典自身が、精度の具体値もフリート全体での性能も開示せず、結果はデータ特性次第だと断っている。私はこれを誠実な書き方だと受け取っている。エージェントの品質はモデルの性能ではなく、与えたデータと検証ルールの品質に支配されるため、他社の数値がそのまま自社に移植できないのは当然だ。だから導入の検証は、ベンダーの実績値ではなく、自社の過去インシデントを正解データにした突き合わせでやるしかない。「20〜40%」という数字も、対象ユースケースを絞ったうえでの値であることを見落とすと、社内の期待値だけが先に膨らむ。
開発を生業にしている会社にとっての含意
SIer や開発会社の経営・事業判断としては、ここが分岐点になる。この構成を作れるチームに必要なのは、LLM のプロンプト職人ではなく、データ基盤 (ETL・レイクハウス・ベクトル検索) を組める人間と、業務の決定ルールを顧客から引き出して形式化できる人間である。前者は既存のデータエンジニアリング人材、後者は要件定義ができる PM/コンサル層で、どちらも多くの受託会社が既に抱えている職種だ。つまり「AI エージェント案件」は新規に AI 人材を採らないと取れない仕事ではなく、既存の要件定義力とデータ基盤の力を、エージェントという出口に接続し直す仕事に近い。自社の提案を「AI を導入します」ではなく「診断ルールとログ基盤を整えたうえで、その上にエージェントを載せます」と言い換えられるかどうかで、単価も受注の質も変わると私は見ている。
(編集レンズ: 実装・運用視点 / 作る側の目線 / 発注側と開発会社への含意)
出典: Accelerating aircraft IFEC diagnostics with agentic AI on AWS
