※本記事は、Jani Cortesini氏(Google Core UX, Strategic Program Manager)による、Google I/O 2026のセッション「Match what your AI does with what users want to do」の内容を基に作成されています。動画の詳細は https://www.youtube.com/watch?v=7UBmLXP_LKw でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。また、参考資料としてGoogleの「People + AI Guidebook」(https://goo.gle/49wODZU)、およびGoogle I/O 2026のProfessional Developmentセッション一覧(https://goo.gle/professional-developer)、Google for Developersのチャンネル登録(https://goo.gle/developers)もあわせてご参照ください。
1. イントロダクション:信頼とHuman-AIアラインメントとは
1-1. AI時代のパラダイムシフト
改めまして、私はJani Cortesiniと申します。Google Core UXでストラテジック・プログラム・マネージャーを務めております。本日は、Googleの「People and AI Guidebook」から得られた考え方をご紹介しながら、ユーザーの意図をAIへのタスクへと翻訳する方法、信頼を築くために役立つ説明の提供方法、そしてエラーをユーザーによるコントロールの機会へと変えていく方法について、皆さまと一緒に探っていきたいと思います。よくある課題を深掘りしながら、具体的な推奨事項もお伝えしますので、ぜひ人を中心に据えたソリューションを実装するための第一歩として、今日の内容をすぐに活用していただければと思います。
私たちはこれまで、AIによってプロダクトの作り方そのものを根本から変えてきました。かつては予測可能なユーザージャーニーを前提にプロダクトを設計していましたが、いまではオープンエンドなシナリオを扱うようになっています。私たちのAIプロダクトは自然言語によって駆動され、同時に複数のモダリティを扱うことができ、さらにはユーザーに代わって行動を起こすことすら可能になりました。こうした能力によって、私たちは非常に幅広いロングテールのユースケースをサポートできるようになった一方で、その裏側にあるユーザー体験の不確実性についても、私たち自身が責任を負う立場になったのです。
1-2. 信頼較正という中心概念
こうした変化は、私たちに新しいアプローチを求めています。信頼というものは、もはやオンボーディング時に一度達成すればそれで終わり、という静的なものではありません。むしろ信頼とは、継続的に較正し続けなければならない、進行中の重要なプロセスへと変わったのです。
プロダクトの能力が向上するにつれて、ユーザーの期待もまた高まっていきます。理想的な信頼レベルとは、ユーザーの期待とプロダクトの実際の能力とが完全に一致している状態を指します。この理想値を上回っている状態を「過信(オーバートラスト)」、下回っている状態を「不信(アンダートラスト)」と呼んでいます。この過信と不信のあいだにある紫色のゾーンこそが、継続的な較正が行われる領域です。ただし、重要な点として、この信頼の較正は決して単独で起こるものではないということを、ここで強調しておきたいと思います。
1-3. 信頼はスパークライン状に変動する
信頼の較正は、システムとユーザーの双方が協働して初めて成り立つプロセスです。なぜなら、信頼というものは高まることもあれば、後退することもあるからです。実際のところ、信頼の推移は先ほどお見せした紫色の線のように、まさにスパークラインのような形を描きます。ユーザーは過信も不信もどちらも経験しながら、そのつど自分の期待を実際のプロダクトの能力に合わせて調整し、継続的に較正していく必要があるのです。
1-4. 信頼はシステムとユーザーの協働で形成される
さらに申し上げると、信頼は各ユーザーがこれまでに積み重ねてきた過去の体験にも大きく左右されます。そして、今日ユーザーが経験することが、次にAIのアップデートをリリースしたときの信頼のあり方を形づくることになります。
こうした状況を乗り越えていくために、私たちが拠りどころとしているのが「AIを人々とともにデザインする、人々に向けてデザインするのではない」という基本理念です。では、具体的にどうすればユーザーが自分自身の信頼を較正できるよう支援できるのでしょうか。その答えは、AIが実際に何をしているのかを明確に定義し、それをユーザー体験を通じてユーザーが本当にやりたいことと一致させることにあります。
そのための最初のステップは、人々が自分のゴールをどのように表現できるかを定め、AIがどのようなタスクを、どのように実行するのかを決めることです。これは「Human-AIアラインメント」と呼ばれる考え方であり、次のセクションで詳しくご説明していきます。
2. アラインメントの基礎とDevelocityでの当てはめ
2-1. アラインメントの定義とリスク
先ほど申し上げたHuman-AIアラインメントについて、もう少し詳しくお話しします。Human-AIアラインメントとは、広く言えば、ユーザーが「何をしたいか」「どのようにそれを実現してほしいか」を指定し、AIの出力を理解・検証しながら、ユーザーが満足するまで反復的にAIを操縦していく、というプロセス全体を指します。そして私たちは、この考え方を実際に活用していくために、3つの基盤となる概念とアクションを用意しています。それが、メンタルモデルを形づくること、役立つ説明を提供すること、そしてエラーを適切に管理すること、の3つです。これらはユーザーの体験を効果的に導き、AIが実際に行っていることとユーザーがやりたいこととを結びつけるための土台となります。
なぜこれが重要なのでしょうか。AIシステムが成功するためには、ユーザーのニーズを明確に理解したうえで、システムの目的を定義することが不可欠だからです。Human-AIアラインメントは、AIモデルがユーザーの曖昧でカジュアルな言葉遣いを正しく解釈し、それをユーザーの本当の関心事に沿った、具体的で実行可能な指示へと変換することを保証してくれます。そして、このアラインメントが対象とするのは、最終的な結果であるタスクのアウトカムだけではなく、そのアウトカムに至るまでのプロセスの両方です。
もしこのアラインメントに失敗すると、たとえば「リワードハッキング」と呼ばれる現象が起こり得ます。これは、モデルが本来意図されたものとはまったく異なるゴールを学習し、実行してしまい、間違ったやり方で結果だけを達成してしまう現象です。そして、この種のリスクは、AIエージェントがユーザーに代わって行動を起こす能力を持つ場合に、さらに増幅されてしまいます。
2-2. 4つの構成要素
Human-AIアラインメントに取り組むための基礎的な出発点は、AIシステムが何をするのかを、4つの中核的な構成要素によって明確に定義することです。ここでは、それぞれをシンプルな例とともにご紹介します。
1つ目は「プライマリーゴール」です。これは、AIが解決すべき具体的な問題そのものを指します。たとえば「コードを生成する」といったことがこれにあたります。2つ目は「サブゴール」です。これは、ユーザーが主目的に取り組む前、あるいは取り組んでいる最中に対応しなければならない、代替のゴールや依存関係、あるいは副次的な問題を指します。たとえば「使用するプログラミング言語を選ぶ」ことがこれに該当します。
3つ目は「アンダースペシフィケーション」です。これは、ユーザーがしばしば説明し忘れてしまう問題の一部や情報を指します。たとえば、開発者がAIに使ってほしい命名規則を指定し忘れてしまう、といったケースがこれにあたります。そして4つ目が「最適化(オプティマイゼーション)」です。これは、ある問題を最適化するさまざまな方法や、あるサブゴールを最適化することが別のサブゴールをどのように損ないうるかを理解することを指します。たとえば、速度を最適化するAIシステムが、その代償として不正確さを生んでしまう、といったケースがこれに該当します。
2-3. Develocityでの具体例とトレードオフ
ここまでの内容を、より実践的な形で理解していただくために、私たちは架空のエンタープライズ向けプロダクト「Develocity」を用いて考えていきたいと思います。Develocityは、生成AIを活用して開発者のコード記述・テスト・共有・管理を支援する統合開発環境(IDE)です。Develocityのモデルは組織固有のコーパスで学習されており、開発者の生産性を高めながら、厳格なコードの一貫性を維持することを目的としたAIコーディングアシスタントおよびエージェントを備えています。
それでは、Develocityにとってのプライマリーゴール、つまりAIがユーザーのために解決すべき具体的な問題とは何でしょうか。その一例として、「組織の承認済みリソースを使用し、組織のニーズとスタイルに合致したコードを効率的に生成すること」が挙げられます。
次に、サブゴールにはどのようなものがあるでしょうか。ここでも、ユーザーが対応しなければならない代替ゴールや依存関係、副次的な問題を指しますが、Develocityの場合であれば、使用するプログラミング言語を決めること、ストレージリソースをセットアップすること、特定のライブラリをインポートすることなどが、サブゴールの具体例として挙げられます。
では、アンダースペシフィケーション、つまりユーザーがしばしば説明し忘れてしまう問題や情報にはどのようなものがあるでしょうか。たとえば、初期化すべき変数の数、具体的な命名規則、あるいは網羅的なコードとみなすための基準などを、ユーザーが説明し忘れてしまうことが考えられます。
最後に、Develocity AIが問題を最適化するためのさまざまな方法と、あるサブゴールの最適化が別のサブゴールをどのように損ないうるかについてです。ここでの例をご紹介します。AIによるコード生成は、ユーザーの効率を高めることができます。しかしながら、純粋に速度だけを最適化してしまうと、AIが人間による監督なしにエラーを自動修正してしまったり、未検証ではあるものの一見効率的に見える手法を用いてしまったりして、結果として意図せずデータ漏洩につながってしまう可能性があるのです。
こうして最善を尽くしても、システムの仕様はユーザーの期待とどうしても食い違ってしまうことがあります。次のセクションでは、その理由と、それに対処するための3つの概念についてお話ししていきます。
3. 仕様と期待の乖離、土台となる3概念
3-1. 乖離の要因とメンタルモデルの定義
ここまでご説明してきたように、私たちがどれほど最善を尽くしてシステムの仕様を定義したとしても、それは必然的にユーザーの期待と食い違ってしまうことがあります。その理由はさまざまですが、たとえば、ユーザージャーニーがオープンエンドであり、たどりうる道筋が無数に存在すること、モデルにプロンプトを与える際の言語そのものに曖昧さがあり、ユーザーがAIにタスクを依頼する方法が人それぞれ異なること、そして何より、ユーザーが自分自身の前提や思い込みをどうしても持ち込んでしまい、システム側にはその前提を見通すすべがないこと、といった要因が挙げられます。
そこで登場するのが、次の3つの概念とアクションです。すなわち、メンタルモデルを形づくること、役立つ説明を提供すること、そしてエラーを適切に管理すること、の3つです。これらは、システムがユーザーの「やりたいこと」とつながり、進化していくための土台となるものです。それぞれについて、順番にお話ししていきたいと思います。
まず出発点となるのが、メンタルモデルです。メンタルモデルとは、AIが何をできて、何をできないのか、そしてどのように動作するのかについて、ユーザーが内面に抱いている信念のシステムのことを指します。人は、プロダクトや場所、あるいは人物など、自分が関わるあらゆるものに対してメンタルモデルを形成します。このメンタルモデルを理解し、それを強化する方法を取り入れることは、ユーザーがAIをプロダクトの中で日常的かつ頻繁に活用していくための直感を養う助けになります。
ここで重要なのは、ユーザーはプロダクトを使いこなすうえで、部分的なメンタルモデル、あるいは十分な直感さえあれば足りるという点です。仕組みを正確に理解している必要はありません。また、メンタルモデルは動的なものであり、外的な要因や経験によって絶えず形づくられ続けているということも忘れてはなりません。ユーザーが今現在持っているメンタルモデルが、そのまま将来のメンタルモデルであるとは限らないのです。
さらに申し上げると、人は実際の現実世界での体験を通じて、深く、そして強固なメンタルモデルを形成します。そして、こうした体験に基づくメンタルモデルは、明示的に教えられた内容すら覆してしまうことがあります。つまり、ユーザーは、オンボーディングやチュートリアルのような強制的な仕組みを通じてではなく、自分自身でAIシステムの境界や限界を実験し、発見することによって、より効果的に学習していくのです。
3-2. 期待設定力とプロンプトへの影響
この発見を通じた学習プロセスが重要なのは、メンタルモデルが「期待を設定する力」を併せ持っているからです。メンタルモデルは、私たちが何をどれだけ信頼すべきか、そしてそこからどのような価値を期待できるかを決める役割を果たします。そして、この期待というものが、ユーザーがAIに対して自分の意図をどのように表現するかを左右するのです。
もしユーザーがAIを過信していれば、AIが自分の意図を読み取ってくれるはずだと期待して、説明不足で曖昧なプロンプトを与えてしまうかもしれません。逆に、AIを不信に思っている場合には、意図せず矛盾した指示を与えてしまったり、あるいはAIが本来提供できるはずの探索的な力を見逃してしまったりすることになります。また、ユーザーが人間並みの理解力をAIに期待している場合には、大きな方向性を伝え、動機づけるような言葉遣いを用いるかもしれません。一方で、期待が純粋に実用的・機能的なものであれば、ユーザーはより明確で詳細な指示をAIに与え、良い結果を引き出そうとするでしょう。
3-3. 説明とエラーの位置づけ
次にご紹介するのが、「説明」という橋渡しの役割を果たす概念です。説明とは、AIがどのように意思決定を行っているのか、あるいはさまざまなユーザーの入力にどう応答しているのかを明らかにする、その場その場での手がかりやシステムからのフィードバックのことを指します。AIが仕様を実行するとき、あるいは実行に苦戦しているとき、説明こそが、システムが自らの限界をユーザーに伝え返すための手段となります。説明は、ユーザーのメンタルモデルを更新し、修正する役割を積極的に果たし、その後のユーザーの入力がシステムの本当の能力とより一致するようにしてくれます。
そして最後に、「エラー」についてです。エラーは、私たちのHuman-AIアラインメントにとっての究極のストレステストであり、現実を突きつけるものです。エラーとは、システムが失敗する瞬間であり、ユーザーが間違いを犯す瞬間であり、あるいはAIがユーザーの意図について誤った前提を置いてしまう瞬間、つまり先ほどお話ししたアラインメントエラーが起きる瞬間のことです。エラーが発生したときには、説明を用いて、ユーザーをそのエラーから丁寧に導き出すことができます。これが重要なのは、正しく扱われたエラーは、ユーザーのメンタルモデルを積極的に改善し、信頼を較正する助けとなる、協働的な瞬間へと変わるからです。
これらをまとめますと、Human-AIアラインメントとは、AIが実際に行っていることが、私たちが本当に望んでいることと一致するようにするための手段だと言えます。これは基盤となる重要なステップです。しかし、これはシステムを使う際のユーザーの期待や、ユーザーがそのシステムで本当にやりたいこととぶつかり合うことがあります。そこで私たちは、メンタルモデルを形づくり、役立つ説明を提供し、エラーを適切に管理することを通じて、継続的な改善のためのデザインを行っていく必要があるのです。それでは次に、これらの概念を実際に活用しながら、より実践的な形でお話を進めていきたいと思います。
4. メンタルモデル形成の実践(Develocity)
4-1. ユーザーの進化という前提
ここからは、先ほどの3つの概念のうち、まず「メンタルモデルを形づくる」という点について、再びDevelocityを題材にしながら、より実践的な形でお話ししていきたいと思います。
ひとつのシナリオを想像してみてください。皆さんが、新しいエンジニアのコホートに対してDevelocityを展開しようとしている場面です。ここで重要な検討事項とは何でしょうか。それは、新しいユーザーは決して静的な存在ではない、ということです。彼らは、たとえば従来型のIDEの自動補完機能のような既存のメンタルモデルを持ち込みながらも、やがて急速に進化し、複雑でコンテキストを踏まえた支援を期待するエキスパートユーザーへと成長していきます。もし静的なペルソナだけを想定してプロダクトを設計してしまえば、ユーザーが成長するにつれてそのプロダクトは破綻してしまいます。私たちは、こうした成長のプロセスに対応するために、これからお話しする3つの課題に取り組むことでデザインを行っていく必要があるのです。
4-2. ブランクスレート問題
1つ目の課題は、「ブランクスレート問題」、つまり利用の出発点であり、初回利用時の問題です。この課題の本質は、オープンエンドなAIコーディングアシスタントに対して、ユーザーが最初に何を尋ねてくるのか、私たちには分からないという点にあります。ユーザーは、まずは一連のゴールやタスクを持って、AIシステムの能力と限界を意図的に探ろうとするものだと考えて差し支えありません。そして、他のAIツールや非AIツールがそれらのタスクをどのようにこなすかという過去の経験を参照しながら、Develocityをどれだけ信頼し、価値があると判断するかを決めていきます。この段階では、ユーザーが本当は何を求めているのかを理解することが重要になります。そうすることで、ユーザーが自社のプロダクトの真の可能性を理解するための、良い土台を築く手助けができるのです。
たとえば、AIがユーザーに明確化のための質問を投げかけることで、AIが思考のパートナーとして機能し、ユーザーのゴールを研ぎ澄まし、その期待を理解する助けとなることができます。タスクが十分に分解され、ユーザーが望むプロセスがAIにとって明確になった段階で、今度はAI側から関連性が高く価値のあるタスクを積極的に提案することによって、ユーザーが自分の意図をより上手に表現できるよう支援することができます。たとえば、何も入力されていない状態のパネルを表示するのではなく、Develocityのパネルが開発者の現在のコンテキストに基づいて、「この関数のバグを見つける」あるいは「ユニットテストを生成する」といったアクションを提案する、といった形です。これは、ユーザーがAIをどのように操縦すればよいかというメンタルモデルを形成する助けとなります。逆に、明確化のための質問への入力や回答を、私たち自身が想定していたニーズではなく、ユーザーの本当の初期ニーズをマッピングするために活用することもできます。
4-3. 古いメンタルモデルの問題
2つ目の課題は、「古いメンタルモデルの問題」、つまりユーザーが以前から持ち込んでくるものにまつわる課題です。ここで、あるシチュエーションを考えてみましょう。新入社員が、Develocityを標準的な予測変換のように振る舞うものだと期待してしまい、その結果、Develocityがアーキテクチャ全体に関わるような大きな変更を提案してきたときに、フラストレーションを感じてしまう、というケースです。
ユーザーは、類似する技術から得た既存のメンタルモデルを再利用したり、それを土台にしたりしようとするものです。過去の経験は、何が基本的な機能であり、何が自分にとって意味のある価値を生み出すのかという信念を形づくります。そして、ユーザーは自分の既存のメンタルモデルを物差しとして、皆さんのAIが自分の根本的な期待からどれだけ逸脱しているかを判断するのです。
では、これにどう対処すればよいのでしょうか。私たちは、ユーザーを明示的にプロダクトの動作方法へとオンボーディングしていく必要があります。ものごとがどのように機能するかを示すオンボーディングフローは、一見すると簡潔で効率的に思えるかもしれませんが、ユーザーは決まってこれらを読み飛ばしてしまいます。チュートリアルはそれよりは多少定着しますが、それはユーザーが目的意識を持って特定の情報を探しているときに限られます。そのため、教えられたメンタルモデルは、往々にして浅く、はかないものになりがちです。先ほど申し上げたとおり、ユーザーは実際の現実世界での体験を通じて、より深く、より強固なメンタルモデルを学んでいくものなのです。
したがって私たちは、エージェント型のワークフローの中でタスクがどのように実行されるのかについて、ユーザーが合理的な作業レベルのメンタルモデルを形成できるようなシステムを設計し、もし既存のタスクや望ましいプロセスからの逸脱を導入するのであれば、それによって得られるメリットが、そのコストを明らかに上回ることを示す必要があります。ここで、ユーザーがオープンエンドなタスク、たとえば「シミュレーション用のアプリケーションを作成する」といった、実行方法が無数に考えられるタスクを与えてきたケースを考えてみましょう。この場合、私たちはAIに、高レベルの意図を優先順位付けされたプランへと変換させ、それをユーザーが調整できるようにする力を与えるべきです。AIは、ユーザーが取りうる異なるアプローチを示し、それらの類似点や相違点、想定される出力の違いを強調して見せることができます。ここで重要なのは、ユーザーが選択肢を比較し、判断を下すための適切なシステム上の手がかりとコントロールを与えることです。これによってユーザーは、実際にエージェントがどのように機能するかについての自分のメンタルモデルを調整し、最終的にはどのプロセスであれば最小限の監督のもとでAIに任せられるかを、十分な確信を持って判断できるようになるのです。
4-4. 初心者から上級者への移行
3つ目の課題は、ユーザーを初心者からエキスパートへと導いていくことです。ユーザーは初期の探索段階を超えていくにつれて、プロダクトから得られる成果を、実際の意思決定や、現実の結果を伴うタスクのために使い始めるようになります。たとえば、Develocityであれば、協働的なワークフローや、AIが複数のステークホルダー間の期待される相互作用をどのように変化させ、形づくっていくのかを考慮する必要が出てきます。ユーザーは、古いメンタルモデルを手放し、新しいものに置き換えていく必要が生じることもあります。これが、スイッチングコストが高くなりうる理由のひとつでもあります。Develocityのような複雑性の高いツールでは、初心者ユーザーが急速にパワーユーザーへと成長していくこともありますが、たとえそうであっても、彼らが100パーセント真のエキスパートになるとは限りません。
彼らは、これまで存在しなかったような新しいタイプのコードレビューの会話に参加する必要が生じるかもしれませんし、レビュアー側もまた、AI特有のレビュー手法や新しい評価フレームワークについてのトレーニングを受ける必要が出てくるでしょう。ユーザーがプロダクトのAI機能に慣れてくると、プロダクトとの関わり方はより意図的なものになっていきます。ここで、プロダクトがユーザーをどのように導くかによって、彼らが得られる恩恵の大きさが決まってくるのです。つまり、ユーザーがタスクや期待の複雑さを増していくにつれて、彼らは必然的にシステムの限界を見つけ出すことになります。だからこそ私たちは、AIが失敗した際には、その失敗を認め、代替案を提示し、ユーザーにフィードバックを求める必要があります。しかし、たとえAIが成功した場合であっても、ユーザーからの問いかけを認め、説明を行い、フィードバックを求めるべきなのです。これによって、ユーザーが機能しているメンタルモデルをより良いものへと置き換えているタイミングについての洞察を得ることができます。
一例として、ユーザーが対応範囲外のプロンプトを入力した場合に、AIの応答がまずその境界を認めるところから始める、という画面の例をご紹介しました。それに続いて、文脈に沿った簡潔な説明が提示されます。そして、代替となるアクションのリストが、ユーザーに前へ進むための道筋を与えます。フラストレーションを和らげるために、ユーザーはさらに詳しく学ぶためのドキュメントへのリンクをたどったり、その応答の有用性について意味のあるフィードバックを提供したりすることもできます。
こうしたメンタルモデルを絶えず手放し、新たに組み直していくプロセスは、今日のメンタルモデルが、必ずしも将来のメンタルモデルではないことを意味しています。しかし、今日ユーザーを導くために用いるメタファーやアナロジー、戦略こそが、明日への土台を築くのです。それでは次に、この考え方を踏まえて、「役立つ説明を提供する」というテーマへと話を進めていきたいと思います。
5. 助けになる説明の実践(Develocity)
5-1. シナリオとプロアクティブな説明
続いて、「役立つ説明を提供する」というテーマについて、これも再びDevelocityのシナリオを用いながらお話ししていきたいと思います。ある開発者が、Develocityを使って複雑なリファクタリング作業を行っている場面を想像してみてください。ここで重要になるのは何でしょうか。それは、信頼こそがこのやりとりにおける究極の通貨だということです。信頼が少なすぎれば、ユーザーはツールを見放してしまいますし、信頼が多すぎれば、検証しないまま壊れたコードを本番環境にプッシュしてしまうことになります。
不信の状態というのは、たとえば画面上でDevelocityが標準的なコードエディタとして振る舞い、AI機能がすべてオフになってしまっている、という状態です。この場合、ユーザーはAI機能が失敗しすぎることを理由に、自らそれをオフにしてしまいます。たとえば、Develocityが内部APIにアクセスできないために序盤で何度か失敗してしまい、開発者は「このツールは使い物にならない」と判断し、その後の正当な提案までも無視するようになってしまう、というケースです。
一方で、過信の例としては、Develocityが完璧にフォーマットされ、構文的にも正確なコードブロックを生成しながら、実際には非推奨だったり、存在すらしなかったりする依存パッケージを幻覚として出力してしまう、というケースが挙げられます。これは非常に微妙なため、注意していなければ見逃してしまうかもしれません。
具体的な例に入る前に、説明をできる限り役立つものにするための考え方について整理しておきたいと思います。説明は、その場の文脈に即して定義されているときに、最も役立つものになります。そのために私たちは、3つの異なるタイプの説明を提案しています。ぜひ、皆さん自身のAIプロダクトや機能に当てはめながら考えてみてください。
1つ目は「プロアクティブな説明」です。これは、AIがどのようにしてある結果にたどり着いたのかを、大まかな因果関係という形で描写し、AIの挙動についてのユーザーの直感を較正するための説明です。これは多くの場合、モデルのchain of reasoning、つまりモデルが入力をどう理解し、タスクについてどう推論しているかを説明する形で、AIの出力に付随して提示されます。
このプロアクティブな説明の一種として、「影響要因の説明」があります。これは、AIの結果に最も大きな影響を与えた重要な要因やデータの種類を説明するもので、「何がシステムをXという結果へと導いたのか」という問いに答えようとするものです。たとえば、開発者に対して「エージェントにスキルを指定することで、使用されるツールの種類だけでなく、その使われ方そのものについても、大幅に良いツール利用につながる」と伝えることが、これにあたります。影響要因の説明は、シンプルな文章やイラストによって、因果関係を一般化してユーザーに分かりやすく示すことができるものです。これによって、AIがどのように結果にたどり着いたのかについての、もっともらしい内部的な説明を、人間の直感と一致させる効果が得られます。なお、この「影響要因」は、AIの出力をデータ上のソースまで事実として遡ることができる「アトリビューション」とは異なるものである、という点には注意が必要です。
もうひとつのプロアクティブな説明として、「対比的説明(コントラスティブ)」があります。これは、AIがある決定を別の決定より優先して選んだ際に、使用された、あるいは使用されなかった特徴や属性を説明するもので、「なぜAIシステムはYではなくXを選んだのか」という問いに答えようとするものです。このコントラスティブな説明の一種として、より介入的な性質を持つ「反実仮想的説明(カウンターファクチュアル)」があります。こちらは、「AIシステムにXではなくYを選ばせるためには、入力に対してどのような最小限の変更が必要か」という問いに答えるものです。影響要因の説明が、ユーザーが因果関係を直感的に理解する助けとなる一方で、対比的説明は、その因果関係の範囲を絞り込む助けとなります。たとえば、同じ入力に対する複数の選択肢を比較し、ユーザーにその選択肢を実際に採用することを求めることなく、出力がどのように変わりうるかを明らかにする、といった形で活用されます。
5-2. 没入的な説明
2つ目のタイプは「没入的な説明(イマーシブ)」です。これは特に、ユーザーが皆さんのAIシステムと時間をかけてやりとりをするシナリオにおいて有用です。ユーザージャーニーの中で、人々が積極的にAIシステムを操縦し、支援していく必要がある場面において効果を発揮します。没入的な説明は、暗黙的なものにも明示的なものにもなり得ますが、いずれも人間の知性に依拠しています。したがって、没入的な説明がどれだけ力を持つかは、皆さんのAI機能やプロダクトがどれだけよく設計されているかにかかっています。設計が不十分なものは、丁寧に設計されたものに比べて、暗黙的な説明をうまく伝えることができません。
ユーザーが皆さんのAIプロダクトとやりとりをする中で、事例に基づく説明は、AIがなぜ、あるいはどのようなときに特定の振る舞いをするのかを示す、関連性のある事例をユーザーに提供します。こうした事例は、ユーザー自身がAIに与えたコンテキストから得られることもあれば、必要であればモデルの学習データやチューニングデータから得られることもあります。事例を分析することで、ユーザーは、AIがなぜ特定の出力を生み出したのかを自ら推測し、その結果を自分の文脈においてどれだけ信頼すべきかを判断できるようになります。たとえその推測が不正確であったとしても、こうした結論はユーザーがAIシステムの出力を生み出す一般的なプロセスを理解し、その出力が自分の目的達成に役立つかどうかを検証する助けとなります。
AIシステムを説明し、ユーザーがより正確なメンタルモデルを構築する助けとなるもうひとつの方法として、動的に実験を行い、「もし〜だったら」という問いを投げかけられるツールを提供することが挙げられます。人々はしばしば、AIシステムがそうした詳細を汲み取ってくれることを期待して、より豊かな文脈情報や、詳細なタスクの説明、より描写的なコンテキストを提供しようとします。これは、AIが協働的に振る舞う、操縦可能なAIシステムにおいて、特に有用です。ユーザーが自分自身の条件でAIと関わることができる体験を意図的に設計することは、理解度と使いやすさの向上、そしてより適切に較正された信頼につながります。
5-3. メトリック駆動の説明
最後の3つ目のタイプが、「メトリック駆動の説明」です。名前が示すとおり、これは結果を提示する際に、モデルの各種メトリックやデータソースを含める説明です。これらは、モデル自体によって生成される場合もあれば、さまざまなデータソースを要約する場合、あるいはモデルが結果を出力した後に計算される場合もあります。
プロダクト体験全体を通じて、ユーザーが接するデータには大きく2つの発生源があります。1つ目は、ユーザー自身が提供したデータであり、ユーザーの入力、フィードバック、プロダクトのログ、選好、履歴などが含まれます。2つ目は、AIシステムの学習やチューニングに使われたデータ、およびシステムが入力特徴量として利用するその他の信号です。ユーザーが提供したデータのうちどの部分がAIシステムによって利用されているのか、たとえばプロンプトやパス検索といった、ユーザーの同意のもとで取得されたデータがどう使われているのかを伝えることは、ユーザーが自分自身の知識とシステムの知識との間の食い違いを見つける助けとなり、結果としてAIがより良い出力を提供する助けにもなります。
こうした透明性は、特にユーザーの方がシステムよりも完全かつ最新の情報を持っている場合に、過信や不当な依存を防ぐことにつながります。また、特定のメトリックは、なぜAIシステムがある結果を生み出したのかについての洞察を与えるとともに、AIの出力がどの水準を超えれば受け入れ可能、あるいはユーザーにとって関連性が高いといえるのかという、明確な品質と確信度のしきい値を確立する助けにもなります。メトリックが容易に理解されるためには、それが皆さんのAIプロダクトに対するユーザーのメンタルモデルと一致している必要があります。これには、モデル自体が生成した、あるいは事後的に評価された技術的なメトリックを、タスクに関連し、ユーザーが複数のAIの出力から選択する際に意味を持つような、指標や表現へと翻訳する作業が求められることもあります。
ここまで、人々がどのようにメンタルモデルを形成し、更新していくのか、そしてそれを助けるさまざまなタイプの説明についてお話ししてきました。ユーザーのメンタルモデルと私たちが提供する説明は、エラーに遭遇した後にユーザーがどのように信頼を再較正するかにも大きく関わってきます。それでは次に、エラーを適切に管理するための実践的な方法について見ていきたいと思います。
6. エラー管理の実践(Develocity)
6-1. ツール誤用とシステム階層エラー
続いて、エラーを適切に管理するための実践的な方法について、これも引き続きDevelocityを題材にお話ししていきたいと思います。
まず、ひとつのシチュエーションを考えてみましょう。モデルがタスクを実行する際にツールを誤った形で使用してしまい、その結果として失敗状態に陥ってしまう、というケースです。エージェントやエージェント型のワークフローは、推論を行い、柔軟に対応し、曖昧さを扱うことに長けているからこそ強力なのですが、その一方で、開発面でも認知面でも、より高いコストを伴うという側面があります。ツールの失敗状態は、さまざまな形で現れます。システム全体の挙動に影響を及ぼす「一般システム」レベルのもの、特定の要素や機能に影響する「部分システム」レベルのもの、そして個々のAIの出力に現れる「特定の出力」レベルのもの、といった具合です。
では、これに対して私たちには何ができるでしょうか。まず最初のステップは、これが「システム階層エラー」である可能性を見極めることです。システム階層エラーとは、AIシステムを構成するさまざまなコンポーネントが互いにうまく連携しておらず、ツール利用やオペレーションの階層関係が不明瞭であることから生じるエラーを指します。私たちのシナリオで言えば、システムはユーザーが適切なエージェントを選択できるよう支援すべきだ、ということになります。
エージェントにツールを追加する際には、それぞれのツールに明確な説明を持たせ、スコープを狭く絞り込むことで、エージェントの混乱を最小限に抑える必要があります。場合によっては、影響の小さい、あるいは不要なツールをエージェントのコンテキストから頻繁に取り除くよう、AI機能そのものをアーキテクチャとして設計する必要すら出てくるでしょう。そして、たとえ最も優れたエージェント型システムであっても、ユーザーに対して「AIの出力はあくまで出発点であり、常に結果を検証すべきである」ということを、常にリマインドしておく価値があります。実際の画面例では、Devloが明確な説明を持つ複数のツールの中から選択を行うchain of thoughtの様子とあわせて、ユーザーに結果の検証を促すメッセージが常に表示されている様子をお見せしました。
6-2. 曖昧なプロンプトとトリップワイヤー
もうひとつのシナリオをご紹介します。開発者が、自分では十分だと思い込んでいる曖昧なプロンプト、あるいは不十分なコンテキストしか与えていないケースです。たとえば、「これを全部直して」といった指示がこれにあたります。
私たちが人間の同僚に対してタスクを依頼するときには、そのタスクの背後にある動機について認識を合わせたうえで、あとは相手の創造性や判断力、専門性を信頼して、プロセスそのものは相手に委ねます。それに対して、私たちはこれまで、AIシステムをより決定論的なものとして管理し、特に曖昧さを乗りこなしたり意図を推測したりすることをまだ信頼していない場合には、具体的なアクション、つまり「どのように」の部分まで細かく指示するという形でAIを扱ってきました。
しかし、エージェント型のワークフローにおいては、ユーザーが「自分が達成したいこと」をシンプルに説明するだけで、AIがその「どのように」の部分を自ら見つけ出してくれるはずだと考えるのも、無理のないことです。この説明には「なぜ」という部分すら含まれることがあり、これが人間に読まれた場合には、反復的で協働的な探索を可能にするはずのものです。話をシナリオに戻しますと、AIの出力に現れるエラーは、ユーザーが「AIの能力にかかわらず、システムが自分の意図を理解してくれるはずだ」という、不正確な期待を持ってしまっていることに起因する場合があります。もしかすると、ユーザーはAIの能力を過大評価し、AIシステムの対応範囲を超えるような入力を与えてしまったのかもしれません。あるいは、自分の入力がAIシステムに送られる前に自動的に修正されることを期待していたのかもしれません。人間であれば圧倒されてしまうような量の指示であっても、AIは処理することができます。ここでの課題は、ユーザーが本当に解決したい問題が何であるかを見極めること、そして時には、その問題自体をユーザー自身に発見してもらう手助けをすることにあります。
推測に頼って黙って失敗するのではなく、AIにあらかじめ組み込まれた明示的な「トリップワイヤー」を用意し、いったん立ち止まってユーザーにフィードバックを求めるよう設計するべきです。たとえば、Develocityが「現在のファイルに3つのデータバグの可能性が見つかりました。タイムアウトの問題、インデックスの問題、接続文字列の問題のどれを意図していましたか」といった形で応答する、というのがその一例です。明確化のための質問を投げかけたり、ユーザーとともにプランを作り上げたりすることは、潜在的な失敗を、協働的で信頼を築く瞬間へと変えることができるのです。
6-3. ループとハルシネーション
最後のシナリオとして、AIエージェントがタスクを部分的に完了させたままループに陥ってしまい、それでいて自分が生産的な作業をしていると平然と幻覚のように報告してしまう、というケースをご紹介します。こうした振る舞いを見抜くには忍耐が必要であり、ユーザーにとっては、プロセスを再起動して重要な進捗を失ってしまうほどのフラストレーションを生み出しかねません。
chain of thoughtによる推論を用いていたとしても、その正確な原因を検証することは難しいという点にご留意ください。なぜなら、こうしたエラーは、モデル自体の問題、あるいはそのモデルを学習・チューニングするために使われたデータの問題に起因する場合があるからです。したがって、エージェント型のワークフローの学習・チューニング・テストに使用されているデータが、実際のユースケースを本当に代表しているのか、そして皆さんのAIの能力のエッジケースを捉えるのに十分に網羅的であるのかを確認する必要があります。
十分なデータがあるにもかかわらず、AIの出力が一貫して不完全だったり不正確だったりする状態が続く場合、あるいは皆さんのAIシステムがユーザーにとって重要な入力に対して鈍感なままである場合には、もしかすると根本にある学習・チューニングの手法そのものに問題があるのかもしれません。これを解決するには、学習・チューニングのプロセスを見直すという、より長期的なアプローチが必要になるかもしれません。しかし、これは同時に、皆さんのAIシステムがループに陥ったり失敗したりしたときに、それがどのように振る舞うべきかについて、現実世界の文脈を提供してくれるユーザーやドメインエキスパートとともに、Human-in-the-loopの評価を実施する機会にもなります。
より直接的な対策として考えていただきたいのは、単一の大きな指示セットには一種の「最終性」が伴ってしまい、それによってワークフローが反復的でなくなり、デバッグもしづらくなってしまうという点です。そうではなく、緊密なフィードバックループを備えたシステムを設計することをお勧めします。内部的には、大きな指示を小さな単位に分解し、進捗を都度保存していきます。そして、一定のタイムアウトに達した時点で、ユーザーに素早い自己修正のパスを提示しつつ、ユーザー自身がコードに対して的を絞った編集を行えるようにする、といった仕組みを取り入れることも検討に値します。画面の例でお見せしたように、Devloの正しい思考のトレースとツールの利用状況をユーザーに対して透明性を持って示すことで、デバッグの助けとなります。
6-4. 暗黙的フィードバックの活用
そして重要なことに、システムはこうしたユーザーによる的を絞った編集を、暗黙的なフィードバックとして捉えるべきです。ツールの利用パターンや成功したステップについての観察も、この暗黙的なフィードバックをさらに豊かにしてくれます。また、「次はこれを覚えておいて」といった、より明示的な指示もまた、高い価値を持つフィードバックの一形態であり、繰り返しの手間を減らし、皆さんのAIがユーザーのワークフローのスタイルに適応していく助けとなります。
こうした、その場その場での修正をフィードバックループへと転換していくことによって、システムは時間の経過とともにモデルを継続的にファインチューニングし、こうしたエラーを未然に防ぎ、体験そのものを改善していくことができるのです。それでは、そろそろまとめに入っていきたいと思います。
7. まとめと4つのテイクアウェイ
7-1. 全体総括とテイクアウェイ1
フロンティアなエージェント型AIへの移行は、人間とソフトウェアとの関係における根本的な転換を意味しています。私たちは、コマンドを実行するだけの決定論的なツールを構築する時代から、意図を解釈し、それに基づいて力強く行動する確率的なシステムを設計する時代へと移り変わっているのです。この新しいパラダイムにおいては、プロダクトの成功は、もはや基盤となるモデルの知性の高さだけでは測れません。むしろ、Human-AIのインタラクションがどれだけレジリエントであるか、という点によって測られるようになります。
Human-AIアラインメントを通じて信頼を築くことこそが、これを実現するための鍵となります。すなわち、「何をしたいのか」「それをどのように行うのか」を定義することです。しかしながら、信頼というものは、オンボーディングの際に一度スイッチを入れて、あとは放っておけばよいというものではありません。信頼とはスペクトラムであり、メンタルモデルを形づくり、役立つ説明を提供し、エラーを適切に管理することを通じて、継続的に較正され続けなければならないものなのです。
AIが実際に行っていることは、常に進化し続けるベースで、ユーザーが本当にやりたいこととマッチしていく必要があります。それでは最後に、ここまでお話ししてきた内容から得られる、4つの重要なテイクアウェイを皆さんにお伝えして締めくくりたいと思います。
1つ目のテイクアウェイです。人間のゴールというものは、本質的に雑然としており、文脈に依存し、そして絶えず進化し続けるものです。抽象的なシステムポリシーだけに頼るべきではありません。Human-AIアラインメントを、継続的な翻訳レイヤーとして活用し、オープンエンドなユーザーの願望を、安全で最適化され、実行可能な制約へと体系的にマッピングしていく必要があります。
7-2. テイクアウェイ2:適応型インターフェース
2つ目のテイクアウェイです。ユーザーが本能的にAIとの協働の仕方を理解している、と思い込んではいけません。ユーザーの期待を形づくっていくことは、私たちの責任です。静的なチュートリアルにとどまらず、システムの能力を段階的に開示していく、適応型のインターフェースを設計する必要があります。ユーザーが、シンプルで支援されたタスクから、複雑で自律的なワークフローへと安全に「卒業」していけるよう、その旅路を足場づくりしていくべきです。
7-3. テイクアウェイ3:過信と不信への対抗
3つ目のテイクアウェイです。AIにおける最大のリスクは、過信と不信の両方にあります。たとえば、幻覚をうっかり無批判に受け入れてしまうことが過信であり、ツールそのものを完全に見放してしまうことが不信です。私たちは、この両方に対して積極的にデザインで対抗していく必要があります。タイミングよく提示される説明や、確信度スコア、検証ステップといった、戦略的な「摩擦」を意図的に導入することで、重要な局面においてユーザーに立ち止まってもらい、なぜその意思決定がなされたのかを理解してもらうようにするのです。
7-4. テイクアウェイ4:エラーをフィードバックに変える
4つ目のテイクアウェイです。確率的なシステムにおいては、エッジケースやエラーは避けられないものです。それらを隠そうとするのではなく、むしろ最も価値のあるフィードバックループとして扱うべきです。システムが失敗したときにユーザーの意図を捉えられるような、優雅なフォールバックと、直感的な修正メカニズムを設計してください。ユーザーによるひとつひとつの修正は、AIの仕様を洗練させ、すべての人にとってプロダクトを改善していくための機会なのです。
結論として、だからこそ私たちは、AIを人々とともにデザインしなければなりません。人々に向けてデザインするのではないのです。AIシステムとユーザーとの間で継続的な較正が行われるようデザインすることによって、私たちはユーザーをAIの出力やアクションの受動的な消費者として扱うことをやめ、能動的な共創者として力を与えることができるようになります。ぜひ今日から、こうした考え方を皆さんの開発サイクルに取り入れていっていただければと思います。
より実践的なツールやフレームワーク、そしてこれらの概念についてのさらに深い考察については、対になっているガイドブックをご参照ください。本日はありがとうございました。