生成 AI は毎日使っているのに、知識そのものは数年前で止まっている自覚がありました。Gemini や Claude を私生活で触っているのですが、どちらも「だいたい分かっている」つもりになっていて、実際には用語の意味も課金の仕組みも説明できない、という状態です。そこで、キャッチアップすべき項目を洗い出したラーニングパスを自分用に作り、端から潰していくことにしました。
構成は 3 レイヤー・12 ステップで、項目数は 50 ほどです。プロンプト入力欄だけで完結する利用者編①から始めて、開発者編・運用者編へ進みます。進め方は「まず自分で手を動かして調べる・検証する」「詰まったところや調べきれなかったところを AI に補ってもらう」「ワークログに残す」の 3 つを項目ごとに繰り返します。
この記事は、そのワークログを清書したものです。個人的に勉強して、個人的にまとめただけのものなので、網羅的な解説になっていない可能性が大いにあります。また、生成 AI まわりは動きが速いので、記載の内容はすべて 2026-09 時点のものになります。
下の表が今回のやることリストです。私と同じような状況にある人は、ぜひこの順番で自分でもタスクをこなしてみることをオススメします。
| 項目 | タスク |
|---|---|
| 生成 AI サービスの見取り図 | 【調べる】3 社(OpenAI / Google / Anthropic)の現行モデルを 1 枚の表にまとめる |
| 思考と推論モデル | 【調べる】各社が提供する機能を整理する 【動かす】同じ課題を推論の強度を変えて解かせ、思考トークン・所要時間・費用を測って比べる |
| コンテキスト | 【調べる】コンテキストが毎ターンどう扱われ、どこで課金されるかを説明できるようにする。セッションをまたぐ継承手段の違いも押さえる |
| AI 検索と Tool Use | 【調べる】Tool Use / Function Calling の仕組みと、Tool / Agent / Skill の線引きを説明できるようにする 【動かす】ツールを使用するような問いを AI にしてみる |
| 音声対話 | 【調べる】各社が提供する機能を整理する 【動かす】AI と音声で対話してみる |
| Artifacts と Canvas | 【調べる】各社が提供する機能を整理する 【動かす】文書を 1 本作り、チャットに戻さず編集を繰り返す |
生成 AI サービスの見取り図
まず各社の公式ドキュメントを開いて、現行モデルを書き出すところから始めました。私がよく見聞きするのは ChatGPT・Gemini・Claude の 3 つなので、対象はこの 3 社としました。
現行モデルを 1 枚にまとめると次のようになります。
| ベンダー | モデル | 位置づけ |
|---|---|---|
| Anthropic | Fable 5.1 | 難度の高い推論と長時間のエージェント作業向け |
| Opus 5 | 複雑なコーディングと企業業務向け | |
| Sonnet 5 | 速度と知性のバランスが最良 | |
| Haiku 4.5 | 最速 | |
| Gemini 3.1 Pro(Preview) | 最上位の推論。複雑な問題解決向け | |
| Gemini 3.8 Flash | ソフトウェアエンジニアリング向け | |
| Gemini 3.5 / 3.1 Flash-Lite | 高スループット・低コスト向け | |
| OpenAI | GPT-6 Astra | 最も高性能。end-to-end の難しい仕事向け |
| GPT-5.6 Sol / Terra / Luna | 高性能 / バランス / 低コストの 3 ティア |
(Models overview – Claude Docs / Gemini models / Models – OpenAI API)
ぱっと見だと、ChatGPT はティアごとの世代番号がだいたい揃っていて分かりやすいと感じました。また、少し前に世間を騒がせた Claude の Mythos は、Fable と同じモデルで、違うのはセーフガードの水準です(Claude Fable 5.1 and Claude Mythos 5.1)。
このほか、オープンウェイトモデルというカテゴリもあり、2026 年の主軸は米国系(gpt-oss・Llama 4・Gemma 4)と中国系(Qwen・DeepSeek V4・Kimi K3・GLM-5.2)に集約されているようです。
比較について
総合順位を見るリーダーボードと、能力別に測る個別ベンチマークがあります。リーダーボードには Artificial Analysis や、日本語なら Nejumi Leaderboard 4 などがあるようです。私が見た時点だと、賢さでは Claude Fable 5.1、速度だと Gemini 3.8 Flash、コスパだと GPT-5.6 Luna がそれぞれ 1 位になっていました。なお、公開スコアの差がそのまま自分のタスクでの差になるとは限らず、最終的には自分のタスクで評価することになります。
課金について
サブスクリプション型と API の従量課金型があります。例えば Claude の Pro プランだと、月額 18 ドルで、Haiku / Sonnet / Opus モデルが使用できます。また、Fable については従量課金で使うための使用クレジットを購入する必要があります。従量課金の場合は入出力トークン数に応じて料金が計算され、2026-09 時点だと、Haiku 4.5 が入力 100 万トークンあたり 1 ドル、Sonnet 5 が 2 ドル、Opus 5 が 5 ドル、そして Fable 5.1 が 10 ドルです。
思考と推論モデル
生成 AI を使い始めると、モデルの選択のほかに、思考の深さを選べることに気付きます。次は、これがなんなのかについて調査しました。
| ベンダー | 呼称 | 制御方法 | 補足 |
|---|---|---|---|
| Anthropic | 拡張思考 → 適応型思考 | effort:low / medium / high / xhigh / max | 旧方式の拡張思考は Opus 4.6 / Sonnet 4.6 で非推奨、以降のモデルでは受け付けない |
| Thinking | thinking_level:minimal / low / medium / high | 推論モデル Deep Think もある | |
| OpenAI | Reasoning | reasoning effort:none / minimal / low / medium / high / xhigh / max | 旧 o シリーズは提供終了(o3-pro のみ残存) |
(Thinking – Claude Docs / Gemini thinking / Reasoning models – OpenAI API)
Claude の場合、Haiku 4.5 は旧方式の拡張思考方式で、設定したトークン予算の範囲内で思考を試みます。他のモデル(Fable 5.1・Opus 5・Sonnet 5)は適応型思考方式で、思考の深さを effort パラメータで制御します。
Gemini の場合も同様に thinking_level で思考の深さを制御することができますが、それとは別に専用の推論モデル Deep Think も用意されています。この推論モデルは 日本数学オリンピックで満点 を取れるほど複雑な推論に特化したモデルで、Google AI Ultra プランで使用可能です(月額 14,500 円)。
ChatGPT の場合は reasoning level で思考の深さを制御することができます。以前は専用の推論モデル o シリーズもありましたが、o3 は 2026-08 に ChatGPT から提供終了し、後継は GPT-5 系に統合されています(o3-pro は Pro 以上のプランで残っています)。なお、歴史的には、o1(2024-09)が商用の推論モデルとして注目を浴びて(OpenAI「o1」とは何か)、その後、o1 と同等の推論能力を低コストで実現したモデルとして DeepSeek-R1(2025-01)が話題となった時期がありました。
なお、私の古い記憶(2022〜2024 年頃)だと、このような推論はプロンプトエンジニアリングの一環として「ステップバイステップで考えてください」のように自分で書いていた記憶があります(思考の連鎖、CoT)。今はモデル自体が長い推論ができるようになって、それをパラメータで制御するという構図に変わったということです。
検証 1
適当に考えた課題を Gemini 3.6 Flash に解かせてみました。Gemini のチャット UI には「強化版思考モード」というのがあり、これを ON/OFF して出力にどういう違いがあるのかを見てみます。課題は「データレイクとデータウェアハウスの長所を組み合わせた分析基盤を設計したい。リアルタイムのログ解析と日次の重いバッチ処理を両立させつつ、運用コストを最小化するための技術選定と、それぞれのトレードオフを比較検討して」というものです。結果をまとめると以下のような違いがありました。
| 強化版思考モード OFF | 強化版思考モード ON | |
|---|---|---|
| 全体の枠組み | Lambda / Kappa に触れ、構成要素を層ごとに並べる | メダリオンアーキテクチャを導入し、なぜそれでリアルタイムとバッチの競合を防げるかを明示 |
| テーブルフォーマット | Iceberg / Delta の 2 つ | Hudi を加えた 3 つ。かつストリーミング時の小さなファイルのコンパクション運用という実運用の落とし穴に言及 |
| コンピュートの比較単位 | コンポーネント単位 | 構成パターン単位(フルマネージド DWH 統合型 / Databricks 一元化型 / OSS コンピュート分離型) |
| コスト最小化 | 自動サスペンド・Tiering という一般論 | スポットインスタンスで 50〜70% 削減という効果量つきの具体策 |
とはいえ、モードが OFF でもそれっぽいことを言ってきたので、比較がどうしても感想ベースになってしまいました。端的に言えば、差が出ない実験を設計してしまった、という結果でした。原因は 3 つ考えられます。1 つ目は Flash 系を使ったことです。Flash は思考量の上限が低めに設計されているので、そもそも差が出にくいモデルでした。2 つ目はタスクに検証可能な正解がないことです。設計論の比較はどちらも流暢に書けてしまい、優劣の判定が読み手の主観になります。3 つ目はトークンや実施時間を測っていないことです。
検証 2
そこで、Claude の Sonnet 5 を使って測り直しました。設定ファイルやメモリの影響を受けないように、空の一時ディレクトリで、ツールを 1 つも与えず、セッションの保存も切った状態で起動します。出力を JSON で受け取ると思考トークン数が取れるので、同じ問題を 3 回流して正答率とばらつきを見る形にしました。課題も数学の素養が必要となる競技プログラミングの適当な難しめの問題にして、正誤の判定が客観的にできるものにしました。最終的な実測が次の表です。
| effort | 正答 | 思考トークン | 所要 ms | 費用(3 回合計) |
|---|---|---|---|---|
| low | 3/3 | 3,772 ±200 | 46,881 ±5,202 | $0.143 |
| max | 3/3 | 23,528 ±10,699 | 221,938 ±99,651 | $0.748 |
まず、今回選んだ問題では effort が low でもあっさり解いてしまいました(少なくとも自力では解けないくらい難しい問題にしてみたのですが…)。数学やプログラミングはそもそも生成 AI が得意としている領域なので、低い effort でも解けてしまうのかもしれません。
ただ、気を取り直して他の項目に着目してみると、正答率は同じ 3/3 なのに、max だと消費した思考トークンが 6.2 倍、所要時間が 4.7 倍、費用が 5.2 倍でした。また、もう 1 つ見えたのが、max はばらつきが大きいことです。思考トークンは low の ±200 に対して max が ±10,699、所要時間も ±5 秒に対して ±100 秒でした。高い推論レベルだとさまざまな推論を重ねて理屈をこねくり回すので、結果が予測しにくくなるのかもしれません。ということは、たとえばバッチ処理のタイムアウト設計などでは effort の設定は賢さ以外の部分でも強く効いてくるはずで、そういった気付きを得られたのは収穫でした。
上述の「理屈をこねくり回すので」に関して、実際に余計なことをしている様子を観測できました。low のときは数学的に解いて終わっているのに対して、max のときは数学的に解いたあとに検算としてプログラム的にも解こうとしていました。それだけならよいのですが、今回の検証の設定としてプログラムの実行ができないようにしていたのにもかかわらず、出力には Python コードに加え、その実行結果が含まれていました(かつ、その Python コードを実際に実行しても得られないフォーマットでした)。これはいわゆるハルシネーション(幻覚)で、所要時間 4.7 倍、費用が 5.2 倍もかかっていながらハルシネーションまで起こしているので、effort は高くすればよいわけではない、という学びが得られました。
effort は「モデルの賢さを上げるつまみ」ではなく「モデルがやることを増やすつまみ」と捉えるのがよさそうです。
コンテキスト
検証を複数日にまたがって実施をするときなどに、生成 AI は前回の内容を覚えているのだろうか?と疑問に思うことがあったので、コンテキストについて調査してみました。
コンテキストは「AI が 1 回のやり取りで覚えていられる短期記憶の容量」であり、コンテキストにはその会話(セッション)内での会話履歴などが含まれます。各モデルのコンテキスト長は、Claude の場合、Haiku 4.5 が 200K で、残りは 1M です。あわせて Claude Code の関連コマンドを整理しました。/context で使用状況とその内訳が見え、/compact で会話履歴を要約して圧縮し、/clear でリセットし、/resume で過去のセッションを読み込んで再開する、という 4 つです。
ここで疑問が 3 つ出ました。会話履歴は毎回の入力に含まれているのだろうか、セッションをまたいでコンテキストを継承するにはどうするのか、/resume があるということはセッションはいつ消えるのか、の 3 つです。
1 つ目については Yes です。LLM の API はステートレスで、サーバ側は会話を覚えていません。ターンごとに会話履歴の全体を毎回送り直しています。だから会話が長くなるほど 1 ターンあたりの入力トークンが増え、セッション全体の累積コストは爆発的に増えていきます。入力トークンが増えると性能が劣化することも知られていて、Lost in the Middle や Context Rot などと呼ばれるようです(LLM のコンテキストが長いと精度が落ちる話)。/compact や /clear は容量対策であると同時に精度対策でもあるということです。
2 つ目については、いろいろと方法があるようです。
| 仕組み | 何をするか | セッションをまたぐか |
|---|---|---|
/compact | 会話履歴を要約してコンテキストを圧縮する。同じセッションを続けるための措置 | またがない |
/resume | 過去セッションの会話履歴そのものを読み込んで再開 | またぐ(履歴を復元) |
| メモリ | 事実をファイルとして保存し、次回以降に関連するものを読み戻す | またぐ(要点だけ引き継ぐ) |
CLAUDE.md | プロジェクトの指示を毎回読み込む | またぐ(手で書く) |
/compact では永続化をするわけではないので、圧縮して捨てられた情報は、メモリや CLAUDE.md にあらかじめ書き出しておかないと失われてしまいます。そのため、/compact 時にどのような観点で圧縮するか指示も出せるようです。とはいえそれでも確実ではないので、残しておきたい情報は明示的にメモリや何らかのテキストファイルに書き出すように指示を出すのが安全そうです。私はこのキャッチアップの作業ログをこまめにファイルへ書き出していますが、結果的にこれが対策になっていました。
3 つ目については、既定で 30 日でした。セッションは .jsonl としてディスクに保存されており、削除は settings.json の cleanupPeriodDays(既定 30)で制御されます。最終更新から 30 日を過ぎた transcript が起動時に削除される仕組みです。
AI 検索と Tool Use
今は当たり前のように生成 AI が Web 検索したりコードを実行していますが、ひとむかし前はそうではなかったはずなので、そのあたりについて調べてみました。
AI が検索して答えられるのは Tool Use (or Function Calling) という仕組みがあるからで、Claude では Tool Use、Gemini や ChatGPT では Function Calling と呼ばれています。昔は「今日の天気は?」と AI に聞くのはバッドプラクティスとされていましたが、時代が変わったところです。
疑問として残ったのは、Tool は自作できるのか、Agent や Skill との違いは何か、の 2 つでした。
Tool は自作できます。というより、「自作したツールを渡す」ことが Tool Use / Function Calling の定義そのものでした。あらかじめ開発者がツールを定義して渡しておくと、モデルは「このツールをこの引数で呼びたい」というレスポンスを返すだけで、実行するのは呼び出し側のアプリです(Tool use with Claude)。モデル自身が何かをするわけではないので、上述した「生成 AI が Web 検索したり」という表現は、厳密にはミスリードなのかもしれません。
私が Web 検索をするコードを書いた覚えがないのに生成 AI が検索できているのは、Claude の場合、自分のコードで実行する client tools(自作ツールはすべてこちら)とは別に、Anthropic 側のサーバで実行される web_search などの server tools があるからです(Tool use with Claude)。私が触っていた Web 検索は後者でした。
Tool と Agent と Skill は、3 つの層として線引きできました。Tool は呼ばれて結果を返すだけの単発の操作で、状態を持ちません。Agent は「考える → ツールを呼ぶ → 結果を見て次を考える」を目標達成までループさせるシステム全体で、Claude Code 自体がこれにあたります。Skill はツールではなく手順そのものをパッケージ化して配布する層です。この 3 層の区別は、開発者編で MCP や Agent Skills を扱うときの土台になります。
音声対話
生成 AI とのチャットが長くなってくると、文字を打ち込むのが大変になってくるので、音声による対話を試してみました。
まず Gemini で音声入力を試したところ、精度は上々で、日常的な調べ物には十分でした。Gemini Live にすると出力も音声になり、AI と会話している感覚になります。Google Docs や Google カレンダーと連携したら秘書のような使い方ができそうだ、というのが率直な感想でした。レビューを調べてみるとカメラとの連携ができる点も便利なようです。
Claude の場合、Gemini Live に準じる機能は voice mode と呼ばれるようで、こちらでも Gmail・Google カレンダー・Slack と連携して音声で操作できるそうです。ただ、私は普段 Claude は CLI から利用しているので、CLI でも音声を使えるか調べたところ、環境を整えたうえで /voice によりマイクと連携することが可能でした。こちらの場合は、マイクで拾った音声が文字として書き起こされるので、必要に応じて修正してチャットすることになります。
なお、試せていませんが、ChatGPT にも GPT-Live 機能(2026-07) があるようです。こちらはフルデュプレックス(聞きながら同時に話せる)であることが売りになっているようで、レビューを調べてみると Gemini Live よりもさらに会話に違和感がないようです。
Artifacts と Canvas
生成 AI とチャットをしながら Web ページを作成している様子を見たことがあったので、Artifacts / Canvas について調べてみました。
そもそも Artifacts / Canvas とは何かというと、AI とのチャット画面の横に開く専用の作業スペースです。Artifacts は主に Claude での名称で、Canvas は Gemini での名称のようです。生成 AI が「質問に答えてくれるチャットボット」から「一緒に作業画面を見ながらモノを作る相棒」へ進化した、と説明されることが多い機能です。なお、かつては ChatGPT にも Canvas 機能があったようですが、GPT-5.5 の頃に Canvas が外れ、チャット内の writing blocks / code blocks に置換されたことが ChatGPT Release Notes から読み取れます。
私が UI 版を使っているのは Gemini なので、Gemini Canvas を試しました。とあるセッションの履歴から、そのサマリを技術ブログとして公開するというテイで作ってみて、直接編集したり変更を指示したりしながら文章をブラッシュアップしていき、成果物を Google ドキュメントへエクスポートしたり、それをもとに Google スライドを作らせたりしてみました(余談ですが、編集可能なスライドが出力されて驚きました。私の記憶は各スライドに画像を貼り付けただけのスライドで止まっていたのですが、どうやら 2026-04 頃から編集可能なスライドが書き出せるようになったようです)。
なお、まだ触れてはいないのですが、Claude Artifacts はまた方向が違い、MCP 接続・永続ストレージ・リンク共有を備えていて、成果物を動くアプリへ拡張できるようです(Turn ideas into interactive AI-powered apps)。私が見たことある Web ページを作成している様子は、この機能だったかもしれません。
Gemini Canvas では Google Workspace との接続が強力で、Claude Artifacts はアプリを作ることができ、ChatGPT は専用画面を持たずチャット UI に再統合しました。3 社 3 様の方針なのが面白いです。
技術ブログの執筆環境
私はブログの執筆を CLI のコーディングエージェントとローカルのメモアプリで行っているので、Canvas のような GUI でやる場合と何が違うのかが気になりました。どちらの方法もまだ使い込めていないので誤っているかもしれませんが、整理すると次のようになるでしょうか。
| 軸 | Canvas(GUI) | CLI × ローカルのメモ環境 |
|---|---|---|
| 何が正か | セッションに紐づくドキュメント。会話を閉じると資産が切れやすい | ファイルが正。過去記事やメモとリンクで繋がり、全体が資産になる |
| 局所修正 | 強い。カーソルを置いて直接タイプ、範囲選択して「ここだけ直して」が自然 | 文字列一致の編集になる。見ながらの微修正は弱点で、エディタ側で手を入れる分業になる |
| 文脈の持ち込み | 毎回のセッションで口頭指示。文体ルールは覚えてくれない | 設定ファイルが毎回同じ規約を渡す。スラッグやタグの規則まで再現される |
| 横断作業 | 開いている 1 本の中で完結 | 検索・一括置換・複数ファイルの同時更新ができる |
| 出力先 | ドキュメントやスライドへのエクスポートが強い | Markdown が最終形。ブログの入稿とは相性がよいが、資料化は苦手 |
| 自動化 | 手作業が前提 | 執筆から投稿までフローとして固定できる |
私の用途では統一的なルールで記事を書きたいというのがあり、そのルールを適用したり過去記事との整合性をとったりしやすい現在の構成は妥当という結論になりました。逆に Canvas に寄せたほうが速いのは、規約のない単発の文章、スライドや配布資料など Workspace に着地させるもの、書きながら大幅に構成を組み替えたいとき、の 3 つが考えられるでしょうか。
おわりに
やったことがある項目ばかりだと思って始めたのですが、実際には知らなかったことのほうが多くなりました。手を動かしてから AI に補ってもらうという進め方は、自分で書いた「分かっているつもり」の記述に対して差分が返ってくるぶん、最初から解説を読むより効率がよかったと思います。
次は利用者編②として、ファイルのアップロードや指示文の保存で AI を自分の文脈に引き込む領域を扱う予定です。パーソナル RAG、メモリ機能、カスタム AI、Computer Use あたりが候補となっています。


コメント