JAXA（宇宙航空研究開発機構）は、小型月着陸実証機「SLIM」の審査プロセスにおいて、閉域クラウド上の生成AIを活用し、安全性と根拠を両立した文書チェックの実証実験を実施。1,000ページ超の技術文書を対象に、短期間での課題抽出や根拠提示の自動化に取り組みました。
本記事では、JAXA宇宙科学研究所 副所長の澤井秀次郎氏にインタビューを実施。PoCにおけるシステム設計や技術的な工夫、さらに将来的な人工衛星運用支援やモデルベース開発（MBD）との連携といった生成AI活用の展望について伺いました。
PROFILE
プロフィール
澤井 秀次郎氏
国立研究開発法人宇宙航空研究開発機構
宇宙科学研究所副所長
宇宙科学プログラムディレクター
宇宙飛翔工学研究系教授
1994年3月、東京大学大学院工学系研究科航空宇宙工学専攻博士課程を修了。同年4月に宇宙科学研究所へ入り、衛星推進系開発などに従事。小型月着陸実証機「SLIM」ではプロジェクトサイエンティストとして、制御工学の知見を活かしてピンポイント着陸技術の確立に貢献している。現在は日本航空宇宙学会会長として学術交流を牽引しつつ、モデルベース開発や生成AIの実装など新しい開発手法の普及にも力を注ぐ。
三好 大悟
株式会社リベルクラフト 代表取締役 データサイエンティスト
慶應義塾大学で金融工学を専攻。卒業後はスタートアップのデータサイエンティストとして、AI・データ活用コンサルティング事業などに従事。その後、株式会社セブン&アイ・ホールディングスにて、小売・物流事業におけるAI・データ活用の推進に貢献。
株式会社リベルクラフトを設立し、AIやデータサイエンスなどデータ活用領域に関する受託開発・コンサルティングや法人向けトレーニング、教育事業を展開。
小型月着陸実証機「SLIM」プロジェクトでのPoC。技術文書の審査における課題とは
まずは今回の実証実験（PoC）の対象となったSLIMプロジェクトの概要をお聞かせください。
澤井 秀次郎氏（以下、澤井氏） SLIM（Smart Lander for Investigating Moon）プロジェクトは、将来の惑星探査に必要なピンポイント着陸技術を、小型探査機を用いながら月面で実証する計画です。
目標着陸地点に対し、これまでは数キロ単位にまで広がっていた誤差を100ｍ程度まで縮めるピンポイント着陸技術を実現すること、そして新しい着陸制御アルゴリズムや軽量化構造などの最先端技術に関する検証を行うのがこのプロジェクトの主な目的でした。
同プロジェクト推進にあたり、生成AI技術を利用した開発プロセスの効率化に向けたPoCがなされています。そもそも、生成AI技術を導入したきっかけは何だったのでしょうか？
澤井氏 JAXAでは衛星や探査機などを開発する際、設計・試作・実装など開発の節目ごとに「審査会」を設け、有識者が関連する技術文書のチェックを行います。今回のPoC導入の背景には、この審査プロセスを効率化したいという審査チーム側からの要望がありました。
SLIMをはじめとする各宇宙機の開発では、構造や電源、姿勢制御など多岐にわたる技術要素ごとに詳細な設計・試験レポート（技術文書）が作成され、その総量はときに1,000ページを優に超えます。
日本語のみならず英語による文書も混在し、また数式や図表も豊富に含まれるため、人の力だけでは、文書同士の整合性や矛盾を短期間で見抜くことは容易ではありません。場合によっては審査会が週に複数回開かれることもあり、10〜20名の専門家がレビューを担当するものの、限られた時間内に大量の情報をチェックする負荷は相当なものでした。
本PoCで目指したのは、膨大な技術文書を漏れなく、矛盾なく、より短時間でチェックする方法論の確立です。
検討初期から複数の選択肢が挙がるなかで、自然言語を扱える生成AIがキーワードとして浮上しました。トレンドとしても技術の成熟度が高まりつつあったタイミングが追い風となり、「生成AIを活用した審査効率化」というアプローチが具体化したのです。
いかに「セキュリティ」と「実用性」のバランスを取るかが取り組みのポイントに
生成AI導入に際し、どのような課題がありましたか？
澤井氏 最大のハードルは「情報の機密性」をどう担保するかです。国の研究機関として、政府のサイバーセキュリティ方針に従う必要があり、外部クラウドとの接続は厳格に制限しなければなりません。LLM（大規模言語モデル）に機密設計データを直接投げ込むという使い方はできないため「クローズドな環境で完結させる」仕組みが必須でした。
PoCでは、具体的にどのようなシステム構成を採用したのでしょうか？
澤井氏 JAXAでは情報の機密度に応じてクラウドに載せてもよい範囲が細かく定められています。今回のPoCでは、機密情報ではなく、上記許容区分に収まるデータだけをアップロードし、専用スペースで一元管理しました。LLM、ベクトルデータベース、チャットボットもすべて同じ閉域クラウド内に構築しています。
機密データを扱わずにPoCを行ったのは、どんな意図からでしょうか？
澤井氏 まず「万が一外部に流出しても差し支えない情報」で実験し、機能面・精度面・運用面の感触を確かめたかったためです。PoCで致命的な穴が見つかれば早期に修正できますし、審査側メンバーにも安心して触ってもらうフェーズが必要でした。今回のテストで基礎的な枠組みは確認できたので、次段階では機密度の高いデータを段階的に適用しながら再評価する計画です。
本運用を見据えたとき、今後クリアすべき技術課題はありますか？
澤井氏 ローカルLLMの活用可能性です。ローカル化すれば情報漏洩の危険性は大きく減り、安心感は増しますが、それによって回答精度や応答速度が下がらないかについては丁寧に検証する必要があります。
このように、セキュリティと実用性のバランスをどこに置くかが、次PoCフェーズの核心の1つになると考えています。
回答の精度を高めるために行った技術的な工夫
AIからの回答の精度を担保するためにPoCで特に工夫された点についてもお聞きしたいです。
澤井氏 一般的なRAG技術（※）ではAIが提示する内容に誤った情報が入り混じることもあるため、精度に懸念が残ります。今回のPoCでは、我々が扱う技術文書の特徴に合わせてデータをチューニングする必要がありました。※生成AIが質問に回答する際、内部の知識を補うために外部情報を活用する手法のこと
三好 大悟（以下、三好） RAGを運用する際、AI本体を改良するのはコストも手間もかかります。そこで重視したのはLLMに参照させるデータをどれだけ整然と蓄積できるかという点です。
今回のPoCでも、投入データを雑にデータベース化した場合と、論文形式の構造を保ったまま整理した場合とでは、回答精度に大きな差が出ることがわかりました。論文は小説などと異なり、章、節や図表番号が明確で構造化しやすいのが特徴です。目次やセクション情報を活かし、データを整理することが精度向上の鍵だと実感していますね。
澤井氏 私たちはAIに対しても、人間の職場での指導と同じようなアプローチを取りました。たとえば、先輩が新人に「この章を読めばヒントがあるよ」「電源系の設計指針はここに書いてある」とアドバイスするように、技術文書の内容をチャンキング（分割）し、それぞれに“付箋”をつけるイメージでAIに提示したんです。
また、JAXAに蓄積されてきた膨大なノウハウ文書も、段階的に参照できるようにしました。たとえ優秀な新人でも、1,000ページを超える文書を丸ごと渡されて「すぐに正しい答えを出して」と言われれば、きっと混乱してしまうでしょう。AIもそれは同じです。大量の情報を一度に与えるのではなく、内容を整理して少しずつ提示することで、AIが適切に理解しやすくなるのです。
つまり、「どこを見れば何がわかるか」をあらかじめ整理して伝えることが、AIの回答精度を高める鍵だと実感しています。
実運用を想定したとき、重要視されたのはどんなポイントでしたか？
澤井氏 何よりもやはり正確性ですね。私たちの場合、スピードについてはそこまで求めていません。たとえば「電源系設計の弱点は？」と尋ねたとき、1〜5分の時間がかかっても問題はありません。人間なら資料を集めて答えを出すのに1週間かかることもあるのですから。むしろAIには、自信がない場合は「わからない」と素直に回答し、自信のある部分と合わせて示してほしいと考えます。
「ここは参考文献を引用して回答している部分」「ここはデータをもとに推測できること」と、回答とともに何を根拠に回答を生成しているのかを提示してもらえれば、審査側は1,000ページの文書を丸ごと読み返す手間を省けますよね。
三好 UIでも、根拠とする箇所がはっきりとわかるようにしています。たとえば1,000ページある文書のうち、この章とこの図表を参考にしたとハイライトするイメージですね。さらに電源系の弱点などの専門的な質問に対しては、JAXAで蓄積されてきた内部ナレッジも加味した索引結果を提示できるように調整しました。
一般企業向けのチャットボットへのニーズはとにかく回答速度の速さにありますが、宇宙開発の現場では時間をかけても多角的にリサーチし、矛盾点を統合的に指摘してほしいケースも多いはずです。今後は検索キーワードを拡張し、より網羅的なリサーチモードを選択できるようにするなどの必要があるかもしれません。
PoCで得られた手応え。将来的には人工衛星の運用支援への活用も
今回のPoCに対しては、一定の手ごたえをお持ちだと推察します。
澤井氏 人間が数週間かけて行う確認作業について、AIが数分で「当たり」を付けられる目処が立ったことは大きいですね。実際の審査会では未運用ですが、1,000ページ級の文書を投入しても根拠提示付きで矛盾点や弱点を抽出できることを確認できたのは大きな進歩です。
将来の生成AIのその他領域への活用に対する展望をぜひお聞かせいただきたいです。
澤井氏 将来的には、人工衛星の運用支援に活用できれば、と考えています。軌道上の衛星から送られてくるバッテリー電圧や姿勢データは多くが数値情報で、運用マニュアルも「こういうときにはこの手順」とある程度、定型化されています。
現状、ベテラン運用担当者は複数のルールを頭に入れ、場合によっては互いに矛盾する指示を調整しながらコマンドを手入力しています。将来的には、AIが衛星から届くデータとマニュアルを突き合わせて最適なコマンド列を下書きする、いわばコード生成に近い行為ができればとイメージしています。
誤ったコマンドは重大事故につながるため、実際の運用の敷居は高いものの、十分実現可能だと考えています。
もう一つ注目しているのがMBD（モデルベース開発）との連携です。現在、私たちは大量の仕様を自然言語で書いていますが、本来はSysMLなど形式言語で表すべき情報が含まれているはずです。生成AIが自然言語からSysMLへ自動変換できれば、モデル化の初期ハードルを大幅に下げられると期待しています。
一方で、宇宙機開発における生成AI活用については、先ほど申し上げた通りローカルLLM環境下で同等の回答精度を出せるかなどについて課題も残ります。何より忘れてはならないのがAIを使いこなすうえでの最終責任は人間にあるというスタンスではないでしょうか。AIの提案を吟味し、必要なら軌道修正する。人間側のマネジメント能力もまた、今後ますます重要になると感じています。
