系統計画においてAIモデルの権限はどこで線引きされるべきか

系統連系検討は、電力系統にプロジェクトを追加する申請から始まります。AIモデルはその申請の解釈を支援できます。しかし、モデルに与える権限は、それが実際に回答できる問いに応じたものであるべきだと私は考えます。たとえ単一のインターフェースが双方の結果を同時に提示するとしても、申請書を読み解くことと、何を検討すべきかを推奨することとは、まったく異なる責務なのです。

私の設計思想は、受付（インテイク）モデルには解釈の提案を許容し、その根拠となったソースを検証可能にしておくべきだというものです。一方で、系統の検討推奨には、それを導き出した計算とルールを保持させなければなりません。この分離が重要になるのは、双方の出力が同等に確信ありげに聞こえながらも、依拠する証拠が異なっている場合です。さらにこれは、より厳格な責務も生み出します。もし解釈に誤りがあった場合、システムには入力を修正し、推奨を再検討するための可視化されたルートが必要になるのです。

整然と記述された申請であっても、設備増強検討が必要になる場合がある

私たちのGridLensデモでは、合成申請データと合成電力系統を用いて、この区別を検証可能な形で提示しています。デモの設定された受付ルールにおいて高い準備度スコアを獲得した、初期設定（シード）の750 MW申請プロジェクト「Tessera Compute」を考えてみましょう。そのスコアが示しているのは申請の準備度です。系統がその連系要求を受け入れられる能力を測定したものではありません。

このデモの直流（DC）熱容量スクリーニングにおいて、起因する最悪のベースケース負荷率は、該当送電線の熱容量限度の92.3%です。ベースケースでは、監視対象の送電線が運用中であると想定されています。監視対象の送電線が1回線停止すると、起因する最悪負荷率は112.4%に達します。これにより、設定された推奨事項は設備増強検討へと切り替わります。

この数値の差異は、本モデル内において実務的な意味を持っています。ベースケースで制限値を下回っていたとしても、設備停止（事故）ケースの安全性が確定するわけではないということです。提示された証拠により、送電線1から248の停止時におけるブランチ548から247が最悪の制約枝線であることが特定されます。系統計画者は、要約文のトーンをめぐって議論するのではなく、推奨の背景にある具体的な系統条件に対して異議を唱えることができるのです。

これは適用範囲を限定した例示です。このスクリーニングでは、大口負荷要求を含め、要求されたMWをスラック平衡による電力注入として扱っており、検証済みの物理的な負荷受電（引き抜き）スタディではありません。また、選定された非放射状送電線の停止のみを対象としており、交流（AC）電圧や無効電力の実現可能性、過渡安定度、単独運転（アイランディング）の検証は除外されています。既存の過負荷は、プロジェクト起因の制約ではなくベースライン条件として扱われます。したがって、過負荷のないクリーンな結果が得られたとしても、それは詳細検討の推奨に過ぎず、連系許可や系統全体の安全性を確定する判断ではありません。

そうした境界のなかでも、この事例は有益な設計上の問いに答えています。設備増強の推奨には系統計算が必要です。用地確保の状況や申請容量についてどれほど理路整然とした説明がなされたとしても、過負荷となったブランチを解消することはできません。受付モデルに推奨を書き換える権限を与えてしまうと、ある問いに関する証拠を、まったく別の問いに関する証拠の代用として通用させてしまうことになります。

AI支援の影響範囲を明確に限定する

GridLensでは、オプションであるモデル支援型の情報抽出を、あくまで助言（アドバイザリー）の位置づけに留めています。創業者の解説動画では、保存された実際のモデル応答を再利用した分析が示されています。これにより、抽出された申請項目や準備度の根拠を提示することはできますが、保存されているキュー・スクリーニングの推奨や検討順位が書き換わることはありません。完全なキュー・スクリーニングでは、決定論的な抽出処理、系統計算、設定されたポリシーが用いられており、言語モデルに計画上の最終判定を下させることはありません。

私がこの境界を支持するのは、審査者がAI支援によって何が変更されたかを把握できるからです。モデルが既存の結果の傍らで新たな解釈を提示する場合、その差異は常に検証可能な状態に保たれます。もし同じ操作によって保存された推奨が密かに書き換えられてしまうと、審査者はどの入力が変更されたのか、計算が再実行されたのか、そして表示されている検討順位がどのバージョンを反映しているのかまで突き止めなければならなくなります。それは、抽出処理の応答単体では到底支えきれないほど重い主張なのです。

系統計画のワークフローにおいて、モデルが担い得るもっともらしい役割は少なくとも2つあります。保持された証拠を用いて算出済みの結果を説明することか、あるいは新たな計算のための入力を提案することです。どちらも有用になり得ます。しかし後者の役割には、より堅牢な改訂プロセスが不可欠です。なぜなら、入力の変更は下流の結果を一変させ得るからです。たとえば、連系点（POI）の変更は、申請概要の文章が洗練されるといった話にとどまらず、系統モデル内でその申請がどこに位置づけられるかを根本から変えてしまうのです。

より本格的なシステムに対する私の設計基準は、その移行プロセスを明示的なものにすることです。提案された修正は、根拠となった原文の箇所、旧値、そして新値を特定できるものでなければなりません。そして適切な審査プロセスを経て承認された後、それらは独立した新たな計算への入力となり、その結果を従前の結果と比較できるようにすべきです。これは私が提案する設計要件であり、現在のGridLensの助言的機能によって実証されている機能ではありません。

これには、追加の審査やバージョン管理といったコストが伴います。自動的に上書きする仕様のほうが提示しやすく、目に見える手順も少なくて済みます。しかしそれは、新たな推奨事項が信頼に足るものかどうかを判断するためにまさに必要とされる情報を覆い隠してしまうのです。修正によって検討対象である物理的な問いそのものが変わる場合、私はこの追加の手間を受け入れます。

決定論的な答えであっても、精密に間違っていることがある

モデルを最終判定から排除しておくことだけでは十分ではありません。決定論的な計算であっても、誤った入力に対して一貫して処理を実行してしまう可能性があるからです。この複雑さに対する正しい対処法は、決定論であることを正しさの証明として扱うのではなく、入力を入念に検証することです。

仮に、ある申請書が2つの接続候補点を曖昧に記載している場合を想定してみましょう。要約モデルはそのうち一方を選択し、説得力があるように提示してしまうかもしれません。しかし、その選定された接続点で熱容量スクリーニングを何度繰り返したところで、申請者が本来意図した内容が解明されるわけではありません。どちらの計算であっても、意図された問いに答えるためには、まずその曖昧さを解消する必要があります。GridLensでは、未解決の連系点がある場合や、抽出の確信度が設定されたしきい値0.60を下回る場合、申請は人間の審査へとルーティングされます。これは未解決の証拠を処理するためのルートであり、完了した技術者の最終決定ではありません。

同じ分離が準備度（レディネス）にも当てはまります。デモの準備度スコアは、申請書類の証拠から導出されたヒューリスティックに過ぎません。スコアが高いからといって送電容量の制約が帳消しになるわけではなく、スコアが低いからといって不正や不備が確定するわけでもありません。推奨事項には、どのような種類の不確実性が残されているのかを明示してほしいと私は考えます。申請書類の証拠不足と、指定された停止条件下での具体的な過負荷とでは、次に取るべき手順がまったく異なるからです。

単一の確信度スコアだけに決定全体の重責を背負わせるべきではないと私が考える理由は、ここにあります。単一の数値にしてしまうと、スコアの低さが抽出の不確実性を示すものなのか、商業的な準備不足によるものなのか、それとも系統側の厳しい制約条件によるものなのかを、審査者が推測せざるを得なくなるからです。これらの問いを明確に区別しておくことで、審査者は結果を真に変え得る証拠の追究に集中できるのです。

改訂への道筋によって推奨事項を評価する

GridLensの解説では、記録されたワークフローとその証拠を確認できます。より大局的な設計基準とは、推奨事項が変わるためには何が変わる必要があるのかを問うことです。修正された申請項目なのか、異なる系統前提なのか、それとも異なる検討ポリシーなのか。そのそれぞれに異なる情報源があり、見直しを行うべき異なる理由が存在します。

以下は、GridLensにおけるこの境界線に関する創業者のウォークスルー動画です。

AI支援を取り入れた計画ワークフローを評価するにあたり、私はこうした依存関係が可視化されているかどうかを基準にしています。有用なモデルの応答は、見落とされていた事実に注意を向けさせたり、修正案を提示したりすることができます。しかし、系統計画の推奨事項に依拠するためには、それを裏付ける入力、計算、そしてルールの記録が不可欠です。審査者が意見の相違を解消し得る具体的な証拠まで遡って追跡できるとき、システムは真の信頼と権威を獲得するのです。