LLMを「使いこなす」ための基礎知識

AIシステム基盤構造から理解する 対象読者: AIを日常的に使っているが、内部の仕組みは詳しくない方
目的: 「なぜAIは指示通りに動かないことがあるのか」を構造的に理解し、より効果的な使い方を身につける
前提知識: ChatGPT、Claude、Gemini等のAIチャットを使った経験があること
推奨: Vibe codingで始めるDeep Learningを試しておくと、本稿の議論がより実感を持って読める

本稿の位置づけ — 楽しさの先にある壁

AIを使い始めた頃は、純粋に楽しい。

チャットで質問すれば的確な答えが返ってくる。文章の下書きを頼めば、一から書くより遥かに速い。コードを書く人なら、Andrej Karpathyが「Vibe coding」と呼んだ体験——「こんな感じのものが欲しい」と伝えるだけでコードが生成される体験——に感動したかもしれない。コードを書かない人でも、企画書や報告書の構成をAIに相談し、「いい感じ」に仕上がる体験は同じだ。

この段階では、AIの仕組みを知らなくても困らない。直感で指示を出し、結果を見て「もう少しこうして」と伝える。試行錯誤のコストが低いから、構造的な理解がなくても成果が出る。

壁は、仕事の量と複雑さが増えたときに現れる。

Vibe codingで小さなツールを作れた人が、複数のファイルにまたがるシステムを作ろうとすると、AIが前に言ったことを忘れる、指示したルールを守らない、修正するたびに別の場所が壊れる。チャットで企画書を練っていた人が、長期プロジェクトの管理にAIを使おうとすると、前回の会話の文脈が引き継がれない、重要な前提条件がいつの間にか消えている。

多くの人はこの壁を「AIの性能が足りない」「自分のプロンプトの書き方が悪い」と解釈する。そしてプロンプトを工夫したり、より高性能なモデルに切り替えたりする。それで一時的に改善することもあるが、根本的な解決にはならない。複雑さが増すと、同じ壁が再び現れる。

壁の正体は、AIの性能でもプロンプトの質でもない。AIシステムのアーキテクチャ——設計構造そのものに起因する原理的な制約だ。ステートレス性、確率的生成、コンテキストウィンドウの有限性。これらを知らずに複雑な仕事をAIに任せようとするのは、レシピ通りに一品は作れるが、品数が増えてタイミングや火加減の調整が重なったときに、食材と加熱の原理を知らないまま「なぜか失敗する」を繰り返すのと同じだ。原理がわからなければ、失敗の診断ができない。

本稿は、この壁を越えるためのテキストである。AIを楽しく使っている段階から、複雑な仕事を設計して任せられる段階へ——その移行に必要な構造的理解を提供する。

本稿の前半（第1〜4章）で述べるアーキテクチャの原理——ステートレス性、確率的生成、コンテキストウィンドウの有限性——は、ChatGPT、Claude、Geminiのどれを使っていても当てはまる。AIチャットを日常的に使っているすべての人が対象だ。後半（第6〜9章）では、これらの原理に基づく具体的な設計手法を解説するが、その使用例としては主にClaude Codeを取り上げている。Claude Codeを選んだのは、本稿で述べるHarness機能（Rules、Hooks、Skills、Agentsなど）を最も体系的に備えているツールだからだ。ただし、設計原理自体はツールに依存しない。第9章ではClaude CodeのHarnessをCodex CLIとGemini CLIに移植する実験を行い、原理のポータビリティ（移植可能性）を実証的に確認している。

Vibe codingの文脈でいえば、Karpathyが述べた「コードの存在を忘れる」開発スタイルは、AI駆動開発の入口として優れている。しかし、入口に留まり続けることはできない。プロジェクトが大きくなれば、設計が要る。仕様が要る。手順の保証が要る。Harnessの設計は、まさにこの「楽しさの先にある構造化」の話だ。

ただし、ここで言う「構造化」は、従来のソフトウェア開発で人間に課されていた重い規律とは性質が異なる。構造化の負担をAIに担わせ、人間は自由な発想と最終判断に集中する——という分業の設計だ。つまり、Vibe codingの「楽しさ」を捨てるのではなく、楽しさを維持したまま、その裏側に構造を入れる。この両立がどのように可能になるかも、本稿の射程に含まれている。