AIがアプリを構築するときの単純なメンタルモデル

アプリ開発者にとっての「AIが考える」とは

人が「AIが考える」と言うとき、たいていはこうした意味合いです：質問を理解し、推論し、答えを決定する。\n\n現代のテキストベースのAI（LLM）に対してより役立つメンタルモデルはもっと単純です：モデルは「次に来るテキスト」を予測します。\n\nそれはがっかりに聞こえるかもしれませんが、「次のテキスト」がどこまで行けるかを見ると印象が変わります。モデルが訓練で十分なパターンを学んでいれば、次の単語（そして次々の単語）を予測することで、説明、計画、コード、要約、さらにはアプリで使える構造化データまで生成できます。\n\n### 目的：数学ではなくビルダー向けのモデル\n\n良いAI機能を作るために基礎数学を学ぶ必要はありません。必要なのは挙動を予測する実用的な方法です：\n\n- 同じプロンプトなのになぜ異なる答えが出るのか\n- なぜ答えが自信に満ちて聞こえても間違っているのか\n- なぜ小さなプロンプトの変更で結果が大きく変わるのか\n- いつ「より強く聞く」のではなく外部データやツールを追加すべきか\n\nこの記事はその種のモデルを提供します：誇大宣伝でも深い技術論文でもなく、信頼できるプロダクト体験を設計するのに役立つ概念です。\n\n### アプリでの「思考」の見え方\n\nアプリ開発者の視点では、モデルの「思考」は、あなたが与えた入力（プロンプト、ユーザーメッセージ、システムルール、取得したコンテンツ）に対して生成するテキストそのものです。モデルはデフォルトでは事実確認をしていませんし、ウェブを閲覧しているわけでもなく、あなたのデータベースに何が入っているかを自動的に“知っている”わけでもありません（それらを渡さない限り）。\n\n期待値を設定しましょう：LLMはドラフト作成、変換、分類、コード風出力の生成に非常に有用です。魔法の真実エンジンではありません。\n\n### 使うパーツ\n\nメンタルモデルをいくつかの部分に分けて考えます：\n\n- トークン（モデルが予測するテキストの断片）\n- コンテキストウィンドウ（一度に“覚えていられる”範囲）\n- 確率（出力が変わる理由）\n- ツールと取得（モデルを実際の行動や事実に結びつける方法）\n- フィードバックと評価（出力を信頼できるようにする方法）\n\nこれらの考え方を使えば、AI機能を一貫性があり信頼できるものにするプロンプト、UI、保護策を設計できます。\n\n## コアループ：次トークン予測\n\n人はAIが“人のように推論している”と想像しがちですが、より有用なメンタルモデルは単純です：非常に高速なオートコンプリートを小さな単位で繰り返しています。\n\n### トークンとは何か？\n\nトークンはモデルが扱うテキストの塊です。あるときは単語全体（「apple」）、あるときは単語の一部（「app」+「le」）、あるときは句読点や空白です。トークナイザによって区切り方は異なりますが、重要な点は：モデルはテキストを綺麗な文として処理するのではなく、トークンで処理するということです。\n\n### 次のトークンを予測して繰り返す\n\nモデルのコアループは：\n\n1. あなたが与えたトークン（プロンプトや過去の会話）を読む。\n2. 次に来る最も可能性の高いトークンを予測する。\n3. そのトークンをテキストに追加する。\n4. 新しく長くなったテキストを入力として、また同じことを繰り返す。\n\nそれだけです。見えるあらゆる段落、箇条書き、理由づけチェーンはこの次トークン予測の繰り返しから構築されています。\n\n### 「思考」＝ガイドされたオートコンプリート\n\nモデルは大量のテキストを学んでいるので、説明の流れ、丁寧なメールの書き方、バグ修正の典型的な記述などのパターンを学びます。質問すると、その学んだパターンに合致し、あなたが与えた文脈にマッチする答えを生成します。\n\nだからこそ、間違っていても自信満々で一貫して聞こえるのです：モデルは「事実を検証する」代わりに「次に来るべきテキスト」を最適化しているからです。\n\n### コードもトークンである\n\nコードはモデルにとって特別ではありません。JavaScript、SQL、JSON、エラーメッセージはすべてトークンの並びです。モデルが有用なコードを出せるのは、一般的なコーディングパターンを学習しているからであり、あなたのチームのエンジニアがアプリを理解するのと同じ意味で「理解している」わけではありません。\n\n## 回答の出どころ：訓練で学んだパターン\n\n「モデルはその回答をどこから得たのか？」と問われたら、最も役立つメンタルモデルはこうです：大量の例からパターンを学び、それらを組み合わせて次に来るテキストを生成している、ということです。\n\n### 訓練はパターン学習であって記憶ではない\n\n訓練中、モデルは多くのテキスト断片（書籍、記事、コード、ドキュメント、Q&Aなど）を見せられます。モデルは単純なタスクを繰り返し練習します：あるテキストが与えられたときに次のトークンを予測する。誤ったら内部パラメータが少しずつ調整され、次回により良い予測がされやすくなります。\n\nその調整が積み重なっていくことで、モデルは次のような関係を内部に表現できるようになります：\n\n- 概念の一般的な説明方法（「コンテキストウィンドウとは…」）\n- 一緒に現れやすい用語（API、認証、トークン）\n- 回答の典型的な構成（定義、手順、例）\n- コードのパターン（SQLクエリの作り方など）\n\n### なぜ一般化できるのか\n\nモデルは統計的規則性を学んでいるため、固定されたスクリプトではなく新しい組み合わせを作れます。多くの「概念を説明する」例と多くの「あなたのアプリシナリオ」の例を見ていれば、それらを融合して応答を生成できます。\n\nこのためLLMはニッチな製品のオンボーディングメールを書いたり、汎用のAPI統合説明を特定のスタック向けに適応したりできます。モデルは単一の保存された段落を取り出しているのではなく、学んだパターンに合致する新しいシーケンスを生成しているのです。\n\n### それは正確な答えのデータベースではない\n\n訓練データに特定の事実（たとえば料金体系や内部ポリシー）が含まれていたとしても、モデルがそれを確実に「引き出せる」とは限りません。訓練は知識ベースにインデックスを付けるような仕組みではなく、むしろ圧縮に近いです：多くの例が重みとなって蒸留され、将来の予測に影響を与えます。\n\nそのためモデルは似た文脈でよく見られることに基づいて詳細を推測し、自信満々に話すことがあります。\n\n### パターンは有用だが正確とは限らない\n\nパターン学習は流暢で関連性の高いテキストを生み出すのに強力ですが、流暢さは真実性と同義ではありません。モデルは次のようなことを起こし得ます：\n\n- 似た概念を混同する\n- 欠けている具体を「もっともらしく」埋める\n- 古い情報や文脈にそぐわない詳細を出す\n\nアプリ開発者への重要な結論は：LLMの回答は通常学習したパターンから来ているので、正確性が重要なら自分のデータやチェックで出力をグラウンド（根拠付け）する必要がある、ということです（後のセクションで扱います）。\n\n## 確率、ランダム性、そして出力が変わる理由\n\nLLMが返信を書くとき、単一の「正しい文」を引き出しているわけではありません。各ステップでモデルは可能な次のトークンの幅広い候補とそれぞれの確率を算出します。\n\nもしモデルが常に最も可能性の高いトークンだけを選べば、出力は非常に一貫するでしょうが、単調で不自然になりがちです。多くのシステムは代わりに確率分布からサンプリングしており、それが制御されたランダム性を導入します。\n\n### 「創造性 vs 一貫性」の調整ノブ\n\n出力の多様さに影響する一般的な設定が二つあります：\n\n- Temperature：値を上げると確率が広がり（多様性増）、下げると上位に収束して一貫性が増します。\n- Top‑p（nucleus sampling）：確率の合計がpになる最小のトークン集合のみを考慮します（例：0.9）。低くするとより安全で予測可能な選択肢に絞れます。\n\nアプリを作る際、これらのノブは芸術的な「創造性」というより次の二択の調整です：\n\n- 安定して再現可能な表現（カスタマーサポートやポリシー、要約に適する）\n- 幅広い探索（ブレインストーミング、ネーミング、代替案生成に有効）\n\n### 自信のある言い回しでも間違うことがある\n\nモデルはもっともらしいテキストを最適化しているため、裏付けが不十分でも確信に満ちた表現を作ることがあります。口調の自信は根拠ではありません。だから、事実が重要なタスクでは取得（RAG）や検証ステップが必要になります。\n\n### 単純な例：同じ関数を様々な正しい方法で書ける\n\n「配列から重複を取り除くJavaScript関数を書いて」と聞くと、次のようなどれも有効な例が返ってくるかもしれません：\n\njs // Option A: concise const unique = (arr) => [...new Set(arr)]; \n\njs // Option B: explicit function unique(arr) { return arr.filter((x, i) => arr.indexOf(x) === i); } \n\nサンプリングの違いはスタイル（簡潔 vs 明示的）、トレードオフ（速度、可読性）、場合によってはエッジケースの動作まで変えます。モデルが「意見を変える」のではなく、複数の高確率な連続を選択しているだけです。\n\n## コンテキストウィンドウ：AIの作業メモリ\n\nモデルが会話を「記憶している」と言うとき、それが実際に持っているのはコンテキストです：今モデルが見られるテキスト（最新メッセージ、システム指示、会話の可視部分）。\n\n### コンテキストウィンドウとは\n\nコンテキストウィンドウは、一度にモデルが参照できるテキストの固定上限です。会話が長くなると古い部分はそのウィンドウの外に落ち、モデルの視界から消えます。\n\nそのため時々次のような挙動が発生します：\n\n- 早い段階で言及した要件を忘れる（「フレンドリーな口調で」や「JSONのみで返して」など）。\n- 以前の決定と矛盾する（変わった変数名、変わった前提）。\n- 小さな誤解が積み重なってチャットが徐々にずれていく。\n\n### 長いチャットがサマリーなしでずれる理由\n\nスレッドにメッセージを積み重ねると、限られたスペースを奪い合うことになります。重要な制約が最近のやり取りに押し出されてしまいます。要約がなければ、モデルは見えているものから重要だと推測するしかなく、確信を持っているように見えても重要な詳細を見落とすことがあります。\n\n実用的な修正は定期的な要約です：ゴール、決定、制約をコンパクトに書き直し、それを挿入して続けます。アプリではこれは自動の「会話要約」として実装されることが多いです。\n\n### プロンプトのコツ：制約は後ろに置く\n\nモデルは出力直前にある指示に従う傾向があります。従って必須のルール（形式、口調、エッジケース）は出力の直前、つまり「では答えを出して」と言う直前に置くと効果的です。\n\nアプリを作るときは、どの情報を常にコンテキストに残すべきか（要件、ユーザーの好み、スキーマ）を決め、チャット履歴を切り詰めるか緊密な要約を追加して必ず含めるようにしてください。構造化プロンプトの組み立てについては /blog/prompting-as-interface-design を参照してください。\n\n## なぜAIは間違うのか：流暢なテキストと現実の違い\n\nLLMは有能な開発者が出しそうなテキストを作るのが非常に得意です。しかし「もっともらしく聞こえる」ことは「正しい」ことと同じではありません。モデルは次のトークンを予測しているのであって、あなたのコードベースや依存関係、実際の世界に対して出力を検証しているわけではありません。\n\n### デフォルトでは何も実行しない\n\nモデルが修正案やリファクタを提案しても、それはただのテキストです。明示的にツール（テストランナー、リンタ、ビルド手順など）を接続しない限り、実際にアプリを実行したりパッケージをインポートしたりAPIを叩いたりコンパイルしたりはしません。\n\nここが重要な対比です：\n\n- 流暢なテキスト：「これは妥当な解決に見えます」\n- 実行で検証済み：「コードがコンパイルし、テストが通り、振る舞いが期待通りである」\n\n### アプリ開発でよくある失敗モード\n\nAIが間違うときは、予測可能なパターンで失敗することが多いです：\n\n- でっち上げのAPIやパラメータ（存在しないライブラリメソッド、間違った関数シグネチャ）\n- エッジケースの誤り（空の状態、タイムゾーン、null扱い、ページネーション境界）\n- 不足しているインポートやセットアップ（忘れられた依存、間違ったファイルパス、欠けている環境変数）\n- 微妙なロジックエラー（オフバイワン、誤ったブール条件、一貫性のない命名）\n- 古い仮定（フレームワークの振る舞いが変わった、非推奨になった設定）\n\nこれらのエラーは周辺の説明が一貫しているため見落とされがちです。\n\n### 経験則：検証してから信頼する\n\nAIの出力はローカルでプロジェクトを動かしていないチームメンバーの素早いドラフトとして扱ってください。信頼度は次を行って急上昇します：\n\n- 単体／統合テストを実行する。\n- リント／フォーマット／ビルドする。\n- 実際の入力で結果を検証する。\n\nテストが通らなければ、モデルの答えはあくまで出発点であり最終解ではないと考えてください。\n\n## ツールは言葉を行動に変え、推測を減らす\n\n言語モデルは「うまくいくかもしれない」案を出すのが得意ですが、それだけではテキストに過ぎません。ツールはAI搭載アプリが提案を検証された行動に変える手段です：コードを実行する、データベースを照会する、ドキュメントを取得する、外部APIを呼ぶなど。\n\n### 実務での「ツール」とは何か\n\nアプリ構築ワークフローでのツールは通常次のようなものです：\n\n- コード実行（Pythonスニペットの実行、プロジェクトのコンパイル、マイグレーションの適用）\n- ドキュメント検索（社内ナレッジベース、製品マニュアル、APIリファレンス）\n- API呼び出し（決済、メール、CRM、フィーチャーフラグ、分析）\n- ファイルの読み書き（設定の編集、テストファイル生成）\n\n重要な変化は、モデルが結果を「知っているふり」をしなくなる点です—実際に確認できるのです。\n\n### ループ：提案 → 実行 → 調整\n\n有用なメンタルモデルは：\n\n1. モデルが提案する（「非アクティブユーザーを見つけるにはこのSQLを実行…」）\n2. ツールが実行する（クエリが実行され、エラーや結果が返る）\n3. モデルがその実出力に基づき調整する（エラーメッセージや行結果を見てクエリを修正）\n\nこうして「推測」は減ります。リンタが未使用のインポートを報告すればモデルはコードを更新します。ユニットテストが失敗すれば、失敗が示すエッジケースを修正するまで反復します（またはできない理由を説明します）。\n\n### 実アプリに対応する例\n\n- データベースクエリ： モデルがSQLを下書きし、DBツールが行数やエラーを返し、モデルが安全にクエリを修正する。\n- リンティング／整形： モデルがコードを編集し、それから eslint/ruff/prettier を実行してスタイルと問題を確認する。\n- ユニットテスト： モデルが関数とテストを書き、テストスイートを実行して失敗に応じてエッジケースを修正する。\n\n### 権限：ツールは本番アクセスとして扱う\n\nツールは強力で危険になり得ます。最小権限の原則に従ってください：\n\n- デフォルトは読み取り専用アクセスを与える（特にDB）。\n- APIキーは必要最小限の権限と環境にスコープする。\n- 削除や払い戻し、メール送信などの破壊的操作は確認を必須にし、呼び出しをログに残す。\n\nツールはモデルを「より賢く」するわけではありませんが、検証ができるためアプリのAIをより根拠あるものにします。\n\n## 取得（RAG）：モデルに正しい事実を渡す方法\n\n言語モデルは、それが「見られる」テキスト上での執筆や要約、推論が得意です。しかし最新の製品変更、会社ポリシー、特定ユーザーのアカウント詳細を自動的に知っているわけではありません。Retrieval-Augmented Generation（RAG）はその簡単な解決策です：まず関連する事実を取得し、それからモデルにそれらを使わせて書かせるのです。\n\n### わかりやすく言うと\n\nRAGは「教科書を開いたAI」です。モデルに記憶だけで答えさせる代わりに、アプリが関連する断片（信頼できるソースから）を素早く引き出してプロンプトに追加します。モデルはその提供された資料に基づいて回答を生成します。\n\n### いつ使うべきか\n\nRAGは、正確さがモデル外の情報に依存する場合のデフォルトとして優秀です：\n\n- 製品ドキュメント、リリースノート、ヘルプセンター記事\n- 社内ポリシー（返金、セキュリティ、コンプライアンス）\n- ユーザー固有のデータ（注文、チケット、アカウント設定）\n- コーパスが大きくて全部プロンプトに入れられない場合\n\nもしあなたのアプリの価値が「我々のビジネスにとって正しい回答」に依存するなら、モデルに当て推量させるよりRAGを選ぶべきです。\n\n### 基本的なフロー\n\n1. 取得：ユーザーの質問を検索クエリに変換し、コンテンツストア（ドキュメント、DB、ベクターインデックス）から上位の関連チャンクを取得する。\n2. 抜粋／引用：それらのチャンクをタイトル、タイムスタンプ、識別子などと一緒にモデル入力に含め、「どこから来たか」を示せるようにする。\n3. 生成：提供されたコンテキストのみを使って答えるようモデルに依頼し、十分な情報がなければそう述べるようにさせる。\n\n### 最大の制限事項\n\nRAGは取得される内容の質に依存します。検索段階が古い、無関係、あるいは不完全な断片を返すと、モデルは自信満々に誤った回答を出すことがあります—しかもそれが「根拠のある」出力に見えるのです。実運用では、取得の質（チャンク化、メタデータ、鮮度、ランキング）を改善することが、プロンプトをいじるよりも精度を高めることが多いです。\n\n## エージェント：モデルがマルチステップワークフローを駆動するとき\n\n「エージェント」とは単にLLMがループで動くことです：計画を立て、ステップを実行し、何が起きたかを見て、次に何をするか決めます。一度だけ答えるのではなく、目標達成まで反復します。\n\n### 最も単純なエージェントサイクル\n\n有用なメンタルモデルは：\n\n計画 → 実行 → 検証 → 改訂\n\n- 計画：目標をいくつかのステップに分ける（「データを見つける、要約する、メールを下書きする」）。\n- 実行：ツールを呼ぶか、下書きを生成して一歩を実行する。\n- 検証：結果を目標と比較する（「本当に顧客の最終請求書を見つけられたか？」）。\n- 改訂：計画を調整して次のステップを取る。\n\nこのループが単一プロンプトを小さなワークフローに変えます。エージェントは単にチャットよりも「自律的」に感じられるのはそのためで、モデルがアクションの選択と順序を自ら決めるからです。\n\n### 停止条件とガードレール\n\nエージェントにはいつ止めるかの明確なルールが必要です。一般的な停止条件：\n\n- 成功基準が満たされた（例：「メール下書きに注文番号と配達日が含まれている」）。\n- 最大ステップ数に達した。\n- 期限やトークン予算に達した。\n- 必須のツール呼び出しが繰り返し失敗した。\n\nガードレールはループを安全かつ予測可能に保つ制約です：許可されたツール、参照可能なデータソース、承認ステップ（人間介入）、出力フォーマットなど。\n\n### ループの暴走を避けるには\n\nエージェントは常に「もう一ステップある」と提案できるため、失敗モードに備える必要があります。予算、タイムアウト、ステップ上限がなければ、エージェントは繰り返し行動を重ねてコストを増大させたり（「少し違うクエリで再試行」など）、無限ループに陥ったりします。実用的なデフォルトは反復回数の上限、すべてのアクションのログ化、ツール結果の検証を必須にし、不完全な回答と試した内容を返して優雅に失敗させることです。これはエージェントを止めない設計よりも良いプロダクト設計であることが多いです。\n\n### Koder.aiのようなプラットフォームの位置づけ\n\nKoder.ai のようなvibe-codingプラットフォームを使う場合、この「エージェント + ツール」のメンタルモデルは特に実用的です。単に提案を受けるだけでなく、アシスタントが機能の計画、React/Go/PostgreSQLやFlutterコンポーネントの生成、スナップショットとロールバックを使ったチェックポイント付きの反復などを支援でき、速く動きながらも変更管理を失わないようにできます。\n\n## プロンプトはインターフェース設計である \nLLMをアプリ機能の裏に置くとき、プロンプトはもはや「ただのテキスト」ではありません。それはプロダクトとモデルの間のインターフェース契約です：モデルが何をしようとしているか、何を使ってよいか、どのように応答すべきか――つまりあなたのコードが確実に消費できるようにするための取り決めです。\n\n良い視点はプロンプトをUIフォームのように扱うことです。良いフォームは曖昧さを減らし選択肢を制約し次のアクションを明確にします。良いプロンプトも同様の働きをします。\n\n### 実用的なプロンプトチェックリスト\n\n出荷前にプロンプトが次を明確にしていることを確認してください：\n\n- ゴール： 成功像（1文）。\n- 入力： モデルが受け取るデータ（無視すべきものを含む）。\n- 制約： 口調、安全ルール、長さ制限、必須／禁止要件。\n- 出力形式： アプリが解析できるような正確な構造。\n\n### 振る舞いを固定するために例を示す\n\nモデルはパターンに従います。望むパターンを“教える”強力な方法は、良い入力と良い出力の例を一つ示すことです（特にタスクにエッジケースがある場合）。\n\nたった一つの例でもバックアンドフォースを減らし、UIが表示できない形式をモデルが発明するのを防げます。\n\n### 散文より構造化出力を優先する\n\n別システムが応答を読むなら、構造化させてください。JSON、表、厳密な箇条書きを要求します。\n\n```text You are a helpful assistant.

Task: {goal} Inputs: {inputs} Constraints:

• {constraints} Output format (JSON): { "result": "string", "confidence": "low|medium|high", "warnings": ["string"], "next_steps": ["string"] }

\n実務では、最も信頼できるプロンプトはあなたのプロダクトのビルドとデプロイのやり方に合わせたものです。例えば、計画→生成→ソースエクスポート／デプロイのような段階があるプラットフォームなら、プロンプト契約も（計画→差分／手順の出力→確認→適用）と段階を明示することでドリフトを減らし、変更をレビューしてから反映するのに役立ちます。Koder.aiの「planning mode」は、このプロセスを明確なフェーズにすることでドリフトを減らしチームがレビューしやすくする良い例です。\n\n## 信頼を築く方法：テスト、評価、アプリでの安全運用
\n信頼はモデルが「自信満々に見える」ことからは生まれません。AI出力を他の依存関係と同様に測定・監視・制約することから生まれます。\n\n### 重要なものを評価する（全部は評価しない）\n\nまずはアプリがうまくこなすべき少数の実タスクを選び、それらを再現可能なチェックに変えます：\n\n- **ゴールデンプロンプト**：キュレートしたプロンプトと期待される特徴（可能なら正確な答え）をリスト化し、リリース前に実行する。\n- **ユニットテスト風のチェック**：モデルが構造化データ（JSON、フィールド、決定）を返すなら、形、必須キー、範囲、許容値をアサートする。\n- **スポットチェック**：週次で最近の会話を軽くレビューして、テストセットが見逃す新しい失敗モードを捕捉する。\n\n### 信頼性を時間で測る\n\n「良いか？」と聞く代わりに「どのくらいの頻度でパスするか？」を追跡してください。有用な指標：\n\n- ゴールデンプロンプトの**パス率**（全体およびカテゴリ別）。\n- 回帰チェック：今日と先週（あるいは前のモデルバージョン）の比較で振る舞いの変化を検知する。\n- ツール成功率（例：有用な結果を返したツール呼び出しの割合）。\n\n### 再現のために十分なログを残す\n\n問題が起きたら再生できるようにしてください。適切にマスクしてログに残す項目：\n\n- **プロンプトテンプレート**と最終レンダリングされたプロンプト。\n- **モデル名／バージョン**、temperature、システム指示。\n- **ツール呼び出しと結果**（入力、出力、エラー、遅延）。\n\nこれによりデバッグが実用的になり、「モデルが変わったのか、それとも我々のデータ／ツールが変わったのか？」に答えやすくなります。\n\n### 本番アプリの安全対策の基本\n\nいくつかのデフォルトが一般的なインシデントを防ぎます：\n\n- **秘密情報をプロンプトやチャット履歴に入れないこと**（APIキー、パスワード、プライベートトークン）。\n- **敏感な出力を表示前にフィルタリング／ブロックすること**（個人情報、医療／法律的主張、ポリシー違反）。\n- 明確な**フォールバック経路**を用意する：自信が低い場合は確認質問、ソースの提示、または人間へのルーティングを行う。