【連載】要求工学における「利用状況」の扱いをめぐる考察：AIシステム要求定義のフロンティアを切り開くコンテキスト・エンジニアリング（第5回②）～「静的な完全さ」の限界：エージェント型AIシステムが形を変えて問い直す、「フレーム問題」のパラダイムシフト～

少しAIの歴史を振り返りながら、前述した内容の意義を考え直したいと思います。

そこで本稿では、第三次AIブームといわれている中、特に生成AIの成功の前後で、アプリケーションシステムの設計で、どのような本質的な違いが出てきたのかを考察します。

1980年代の第二次AIブームでは、知識表現やルールを増やしていけば次第に人間の知能に近づくというアプローチが主流でした。

例えば、よく知られた研究に、1971年のSRI International（旧スタンフォード研究所）で開発された、AIによる自動計画立案のためのSTRIPS（Stanford Research Institute Problem Solver）と呼ばれるシステムがありました[1]。

このシステムは、AIが「目的を達成するためにどのような行動をどの順番で取るべきか」を計画するための形式的な枠組みを提供しました。

同じくSRIで開発されたShakeyという移動ロボットのために使われた他、その後のAI計画研究に大きな影響を与え、PDDL（Planning Domain Definition Language）[2]などの標準的な記述言語の基礎にもなっています。

自分で計画を立てるのでAIと呼ばれたわけですが、実はその計画をどうやって立てればよいかというメタルールは、人間が頑張って定義していたのです。

失敗しない計画を立てられるようにするためには、起こり得るあらゆる状況を想定しながら抜け漏れないメタルールを定義しておかなければならないわけで、当時のAIは結局のところ、人間が定義したルールに従って動いているだけでした。

人間の知能がメタルールに還元できるとか、メタルールを充実させれば人間に近づくはずだというアプローチには思い上がりがあるのではないか、という批判もありました。

例えば、ルーシー・サッチマンは、事前に全ての状況（コンテキスト）を想定し、完全なプラン（計画）を立てることは不可能であるという「計画の限界」を指摘しました[3]。

work-as-imagined（WAI）とwork-as-done（WAD）は、人間工学の領域でよく用いられる概念で、「そうするだろう」と想定・期待されていることと、実際に人がすることの間には大きな違いがあり得ることを指摘する際によく用いられます[4]。

work-as-imaginedとは設計者や管理者、規制監督者、当局が、「起こる」あるいは「起こるべき」と考えていることを表し、一方、work-as-doneとは「実際になされること」を表します。

この違いは、評価する立場によって「法令違反」「手順逸脱」「ヒューマンエラー」と捉えられることもあれば、「状況適応」「創造的対応」「レジリエンスの発揮」として肯定的に評価されることもあります。

Validationの過程で、実際のユーザーを被験者としたユーザビリティテスト（Usability Testing）をやったことがある人なら、次のようなことを経験していることと思います。

設計時に十分検討した(work-as-imagined)はずなのに、そのどれにも一致しないwork-as-doneを目の当たりにすることになるわけです。

これに対し、従来の設計された人工物だと為す術がありません。全く状況に沿わないヘルプメッセージやガイドを出し続けたりします。そこに設計者がいれば、どうしても介入したくなるはずです。

そういった状況を目の当たりにした後では、どんなアドバイスが有効か、それほど困難なく思い付くからです。

本来、どんなヘルプメッセージやガイドがふさわしかったのかを考えることは難しくない、とも言えます。

難しいのは、その状況を設計時にあらかじめ想定することの方でしょう。

被験者はそこでシステムの使用を諦めて投げ出す場合もありますが、不満を爆発させながらも、そこを何とかうまく切り抜けることも結構あります。

レジリエンス・エンジニアリングの提唱者であるエリック・ホルナゲル氏が指摘する[4]ように、うまくいっているのは、いつも状況が同じであるからではなく、何がしかの揺らぎは常に発生していたとしても、多くの人はその違いを吸収しながらシステム全体としてうまく機能するように振る舞っているからなのです。

直面している状況に応じて経験的な〔レギュラリティー〕を引き出して臨機応変に対応しているのです。

それがいつも成功するわけではないですが、思考停止して何もしないよりもずっとうまくいく可能性が高まるはずです。

このような批判があるにもかかわらず、あらゆる状況を想定した前提での「完全な計画」へと突き進むアプローチは繰り返されてきました。しかし、それは思い上がりというよりは、コンピュータを動かすにはそうするしかなかったからでもありました。

コンピュータは融通の利かない「律義な作業者」のようなもので、動作させるには一から十まで明確な指示が必要です。

状況に応じて判断したり、気を利かせて動いてくれることはありません。

そのため、動作を実現するには、詳細なプログラム（コード）によって、全てを事前に定義しておく必要があります。

最終的にコードが必要であることは、実は上流の活動の目的や範囲、方法論に大きな制限や影響を与えています。例えば、モデル・計画（プラン）・機能定義を含むルールなどを必要な分、漏れなく記述しなければならないことが挙げられます。

重要なポイントは、プログラム（コード）は出荷されたり運用されたりする前までには修正が終わってなければならないことです。

そもそもプログラムとは、「あらかじめ書かれたもの」という意味です。あらかじめ決定しておかなければならないものなのです。

そのためには、起こり得る状況や「Work-as-imagined」（想定された仕事）の抜け漏れのない完全な把握と記述が必要になります。

しかし先にも述べた通り、検討すべき状況の因子が多過ぎることや、モデルが扱うべき因子を取捨選択する基準の設定が難しいことから、モデル化、法則化、ルール化、言語化というアプローチの限界に突き当たります。

関連記事：　【連載】概念モデリングを習得しよう：概念モデリングとは（第1回）

これは、従来よりAI研究の領域でよく知られた「フレーム問題」[1][5][6]と呼ばれていたものと同型の問題です（図表2）。

フレーム問題は、AI領域以外でも、認識論や哲学などからも注目されてきた問題であるため、問題の定義そのものにもさまざまな議論があり、オーソライズされた定義を示しづらいものです。

ロボットやAIの行動計画（planning）の場面において、机の上にあるコーヒーカップを移動させることを考えてみます。

コーヒーカップを動かすと、中に入っているコーヒーも一緒に移動します。しかし、机は移動しません。コーヒーカップの素材は変化するでしょうか？机の温度は？机の傾きは？要するに、考慮すべきフレームの中に入る因子と考慮する必要のないフレームから除外する因子をどう決めればよいのかという問題になります。

漏れなく検討しようとするならば、無限に因子が挙げられるため長考に入ってしまうと、図表2のようにロボットもAIも動かなくなってしまうことでしょう。

従来、フレーム問題は「AIには解けないが、人間はそれを問題としない」といわれてきました。

しかし、先述してきた通り、システム開発の場面のように、あらかじめモデルに含める範囲を決めなくてはならなくなった途端、設計者もフレーム問題に突き当たるわけです。

つまり、フレーム問題は「AIと人間の差によって発生しているわけではなく、あらかじめモデル化しようとするから発生する問題」だと捉えることができます。

先にユーザビリティテストの例で、設計者が想定しなかった状況に陥ったとしても、被験者の人間は、その状況をうまく切り抜けることが結構あることを説明しました。人間は経験とその時の状況を、設計者があらかじめ措定したフレームとは無関係に、都度都度で自ら因子を取捨選択して解決を試みるからでしょう。

最新のAIなら、入力として受け付ける因子を選別することや、受け取った各因子をどう処理するかということを、あらかじめ完全に決定しておかなければならないという呪縛から設計者を解放します。

多くの人が期待しがちなこと〔レギュラリティー〕については、言わなくても推測してくれます。

人間が意図することや期待を、かなり推し量ってくれているように見える振る舞いができるようになってきています。

その能力を十全に引き出す仕組みが、先に示したReActやReflexionといった研究や、それらの中で使われている手法を組み合わせたものです。

従来のシステムは、設計時に選んだ入力因子以外の文脈情報を入力する術がありませんが、最新のAIシステムは動的に入力因子とその値の情報を増やせます。

従来のロボットは、「テーブルの傾き」を入力として受け付けるように設計していなければ扱えませんが、昨今のAIシステムでは、その状況が起こった時に「テーブルが傾いた」と情報を付け加えればよいのです。

最新のAIは自然言語という柔軟なインターフェースを介して、動的に新しい情報をコンテキストとして取り込めます。

従来は、テーブルが傾くことを想定し、例えばそこにセンサーを付けることで情報を取り込める仕組みをあらかじめ用意しておかなければなりませんでした。

最新のAIシステムなら映像から特徴のある動きを「テーブルが傾いた」と言語化して抽出し、それを次のインプットに渡すようなことが可能になったわけです。

とはいえ、システムの設計者が相変わらず設計時の因子の範囲しかコンテキスト情報として取り扱わないようにしてしまったら、結局従来システムと同じ結果になってしまいます。

ですから、動的コンテキストをどう扱うかについて、本質的に従来とは異なる発想やアプローチでのエンジニアリングが必要になります。

この動的なコンテキストを扱う新しいアプローチは、コンテキスト・エンジニアリング（Context Engineering）と呼ばれる、最近注目を集めている領域の核心です。

動的コンテキストの範囲をどう選ぶかという問題は設計者に任されるため、本質的にフレーム問題の再来と言えます。

このことから、AIの進化はフレーム問題を解決したのではなく、問題を新たな形で再提示したと言えるでしょう。

静的な因子の選別からは解放され、従来よりはるかに柔軟性を持ったわけですが、結局今度は、動的に膨大な文脈のどこを言語化・記号化・表出化してAIに与えるかという問題に変形されて現れています。その解決には、これまでのAI開発にはなかった新しい発想が求められています。

このためコンテキスト・エンジニアリングという新しい分野は、フレーム問題の新しいバージョンであると捉えることができます。

動的に状況を把握しようとするとき、人間だったらどうするだろうかと考え、それをまねればよいのではないかという発想は普通に出てきます。

人の感覚器がセンシングする範囲と限りなく近づくようにすれば、より人の判断に似てくるかもしれません。

そう考えると、このフレーム問題の新しいバージョンは、「記号接地問題」*１とも地続きになっているようです。もし、AIとは違って人間が記号接地できているというのであれば、能動性を持って動ける身体性や、感覚器官が似てくれば人間と同じように記号接地できるのではないかという考えが当然出てくるからです。

従来より、システムのモデル化や設計においては、必ず最初にコンテキスト図[7]あるいはそれに相当する図を描くことから出発するのが一般的と言ってよいでしょう（図3）。

システムの境界（スコープ）を明確に定義することがプロジェクト成功の鍵です。コンテキスト図は、その目的のために不可欠なツールです。

システムの開発者は、人工物としてシステム化する範囲、スコープを明確にすることが重要な仕事です。設計を進めて順次詳細化する過程で、それは扱う因子を選別して明確にするという静的なスコープ定義方法とも言えます。

新しいAIシステムでは、システム運用時に動的にこのスコープを変更できることになります。

それでも無限の文脈情報を与えられるわけではないので、動的にどういう戦略でスコープを決定するかという問題が代わりに発生します。

ここで確認しておきたいことは、IoTシステムで問題となるような、運用時にシステム連携してつながる範囲が動的に広がっていくこととは質の違うスコープの変動を含んでいるということです。

AIエージェントが互いに連携し、つながっていくことによる広がり方はIoTと同じでしょうが、それぞれのAIシステムは自らが扱う因子を動的に拡大できるというスコープ変更ですから、全く質の異なるものだと言ってよいでしょう。

だからこそ今、コンテキスト・エンジニアリング[8]が注目されているのです。

コンテキスト・エンジニアリングは、システム開発におけるコンテキスト図定義のニューバージョンであると捉えることもできます。

肝心なこととして、従来通りの考え方でコンテキスト図を描いたり、それを精緻化していくだけではうまくいかないことが挙げられます。

従来のコンテキスト図は、今から作るシステムを中心として、関係する要素を網羅的に列挙し、その間に静的な境界（スコープ）を定義します。

現在のAIに適応するには、目的や機能に照らして本来扱うべきシステム（それを担うのが従来的なシステムなのか、AIなのか、人間や組織なのかを最初から区別することなく）を中心に据え、ズームアウト（構造拡張）や目的-手段階層をのぼった（意味拡張）上で詳細を検討していくと良いのです。

どうしても人間でなければならない部分は、後で人工物としてシステムの外側に位置付けます。

人間でなければならない部分は、以下のように大きく二つの理由によることになるでしょう。

• 人間が判断・責任を取るべき部分
• 従来システムやAIが不得意なので、人間が実施せざるを得ない部分

このようなアプローチを取ることで、よくやってしまいがちな、人間が行っている業務やその一部を、そのままAIに置き換えようとすることに起因する失敗を防ぐことができるようになります。

現時点（2025年冬）でのコンテキスト・エンジニアリングでは、主にシステムに与えるべき動的な文脈の範囲をどうコントロールするかという問題に取り組んでいます。

このパラダイムシフトこそが、従来のコンテキスト図およびその定義方法ではAIシステムに適用できない理由であり、コンテキスト・エンジニアリングが重要視される理由です。

ですから、これからの設計者にはコンテキスト・エンジニアリングは、絶対に避けられない領域となっていくことでしょう。

コンテキスト・エンジニアリングの中で用いる手法では、動的にどの因子を選ぶかという戦略の話だけではありません。

例えば、Reflexionが提案した長期記憶と短期記憶の仕組みに何を残すと良いかとか、それらを使用したメタ認知の機構なども含む、従来よりずっと人間に似た仕組みを取り入れた興味深い領域にもなっています（図表4）。

Reflexionのようなシステムにおいて、長期記憶すべきことは失敗の反省だけではなく、さまざまな要因で揺らいだシステムをどうやってうまく回復させたのかという成功への秘訣を含めることも、おそらく有効でしょう。

先に紹介したレジリエンス・エンジニアリングの提唱者であるエリック・ホルナゲル氏は、図表５に示す通り、従来の安全性に対する考え方をSafety-1と位置付け、それだけでは不十分だとして、対照的なSafety-2の考え方を示しました[4]。

図表5のヒューマンファクターの項目に現れる「人間」を「AI」に置き換えて考えてみると面白いと思います。

AIでも同じように「パフォーマンス変動の役割」は、「有害であり、できるだけ防ぐべき」という部分に注目が集まりがちですが、設計時に想定していない状況に至っても柔軟に対応できるためには、「必然的で有用」でもあるはずです。

監視され、管理されるべきことなのも同じです。ホルナゲル氏は、同文献[4]の中で、以下のように記しています。

Safety-2では、うまくいかないことだけでなく、うまくいったことにも着目し、失敗からだけでなく成功したことから学ぶことが重要であると考える。悪いことが起きるのを待つのではなく、普通のことしか起きていないように見える状況において、何が実際に行われているのかを理解しようとすることが重要なのである。Safety-1では、人々が単純に手順に従い、想像されているように作業を行っているがゆえに物事がうまくいくと仮定する。Safety-2では、人々が現在と将来にわたり発生する状況側からの要求に対処し、必要な調整をつねに思慮深く行っているから物事がうまくいくと仮定する。この調整がどのように行われているかを知り、そこから学ぶことは、希にしか起こらない望ましくない結果が生じた原因を探求するよりもずっと重要なのである!

Safety-2の考え方をコンテキストの中に取り入れるアプローチは一例に過ぎません。

生成AIの本質的な強みとコンテキスト・エンジニアリングにより、事前に完全なプランやモデルを与えなくても、その場の状況に応じて「だいたい期待通りにうまくやってくれる」という新しい可能性が生まれました。この領域には、従来の設計思想にとらわれない創造的かつ本質的なアプローチが、まだ数多く残されているのです。この特徴を十分に活用していきたいものです。

*1) 記号接地問題（Symbol Grounding Problem）[5][10]とは、人工知能（AI）システムが扱う記号やシンボル（例：「猫」「りんご」といった言葉）が、現実世界の意味や実体とどのように結び付くか、という根本的な問題です。AIが「猫」という記号をただの文字列として扱うのではなく、現実の猫という実体と結び付けて理解できるかどうかが問われています。

[1] 人工知能学会 (著, 編集), 「デジタル人工知能学事典 [CD-ROM付]」 , 共立出版

[2] https://en.wikipedia.org/wiki/Planning_Domain_Definition_Language, 「Planning Domain Definition Language」, Accessed Sep 29, 2025.

[3] ルーシー・A・サッチマン 著， 佐伯 胖 監訳，上野直樹，水川喜文，鈴木栄幸 訳. 「プランと状況的行為─人間- 機械コミュニケーションの可能性─」, 産業図書（株）（1999）

[4] エリック•ホルナゲル, Safety-1 & Safety-2—安全マネジメントの過去と未来, 北村正晴,小松原明哲監訳. 海文堂出版,2015

[5] 土屋俊, 中島秀之, 中川裕志, 僑田浩一, 松原仁, 「AI 事典」, 株式会社ユー・ピー・ユー

[6] 大澤真幸, 松尾豊, 今井むつみ, 秋田喜美, 「生成AI時代の言語論 」, 左右社

[7] サンフォード フリーデンタール, アラン ムーア, リック スタイナー (著), 西村 秀和(翻訳), 「システムズモデリング言語SysML」, 東京電機大学出版局

[8] Lingrui Mei, Jiayu Yao, Yuyao Ge, Yiwei Wang, Baolong Bi, Yujun Cai, Jiazhi Liu, Mingyu Li, Zhong-Zhi Li, Duzhen Zhang, Chenlin Zhou, Jiayi Mao, Tianze Xia, Jiafeng Guo, Shenghua Liu, 「A Survey of Context Engineering for Large Language Models」, https://arxiv.org/abs/2507.13334