「1M トークン全部使ってください」と頼める LLM が手に入った日、私は少し興奮しながら、机の引き出しに溜まっていた12年分の個人開発メモをスキャンし始めました。アプリの企画書、AdMob のメディエーション設定の覚書、ストア審査対応の控え、ユーザーレビューへの返信下書き — 紙とテキストファイルが入り混じった、自分でも全体像を把握しきれなくなっていた量です。
それから2ヶ月、ほぼ毎日 Gemini 2.5 Pro の長文コンテキストに何かしらを投げ込んで暮らしてきました。コードレビュー、リサーチ、運用メモの整理、原稿のチェック。やってみて初めて「1M が活きる作業」と「短文を何度も投げた方が早い作業」が、思っていた以上にはっきり分かれていることに気づきました。今日はその境目を、できるだけ正直に書き残しておきます。
どんな環境で2ヶ月回したか
実運用環境は地味なものです。手元の MacBook Pro から AI Studio と API を半々で叩き、コンテキストは少ないときで 5万トークン、多いときで 80万トークン前後。アプリ事業は個人で12年続けていて、企画書もメディエーション設定の覚書も、年度ごとのフォルダをまたいで散らばっています。並行して続けているアート活動の応募要項や控えも混じっていて、要するに「同じ人間が長く続けた仕事の、テキストとして残っているもの全部」が題材でした。
費用感も簡単に共有しておきます。Gemini 2.5 Pro の長文プロンプトは、入力トークンが伸びると確実にコストに跳ね返ります。2ヶ月で投げた約 110 リクエストの合計が、ざっくり数十ドル規模に収まりました。1リクエスト数百円〜千数百円という体感です。短文 LLM コールに慣れていると最初は驚きますが、「人を1人雇って整理を頼む」と考えれば桁が違うので、私は今のところ納得して払っています。
向く作業 1 : 散らばった長いコンテキストを1回で俯瞰する
これが最も価値を感じた使い方でした。
12年分の運用メモを 60万トークンほどに詰め込んで、「2014年から今までで、ユーザーレビューに同じ謝罪文を何度使い回しているか」と聞いてみたとき、出てきた答えがかなり鋭かったのです。具体的な文面と回数、年ごとの傾向、そして「2019年以降に語彙が硬くなっている」という指摘までついていました。
短文 LLM に小分けで投げると、こうした「全体を見渡したときにしか見えない傾向」はまず拾えません。RAG で関連箇所だけ引いて要約させても、断片の集合は得意でも、全体の流れを語ることは苦手です。1M コンテキストは、検索ではなく「読書」に近いことができるのが特徴だと感じました。
個人開発を長く続けていると、日々の修正はどうしても目の前の一画面、一関数といった部分最適に偏ります。全体の寸法を測り直す視点は、忙しいほど後回しになりがちです。長文コンテキストは、その「全体を一度に見渡す」工程を、地味ですが確実に肩代わりしてくれる道具になりました。月に一度、散らかったメモ全体を読ませて傾向を聞くだけでも、自分の運用の癖が見えてきます。
向く作業 2 : 大量のMDX記事のクロスチェック
もう一つ実用的だったのが、Gemini Lab を含む4サイト分の MDX 記事を、まとめてチェックする使い方です。
たとえば「Claude Lab で1ヶ月以内に書いた記事の中で、Gemini Lab の既存記事と内容が被っているものはどれか」を、両サイトの記事HTMLをまとめて投げて聞きました。Pro は重複箇所を slug 単位で列挙してくれた上に、「重複しているがアプローチが違うので残してよい例」と「内容が薄く重複している例」を分けて返してきました。判断のための前処理として十分に使える精度でした。
ただし、これは入力サイズが 30〜50万トークン程度に収まるとき限定の使い方です。それ以上になると、後述する精度低下が露骨に出てきます。
向く作業 3 : 設計レビューでの「過去の自分の発言」突き合わせ
設計判断を変えるとき、過去にどう書いていたかを Pro に持たせると、議論が早くなりました。
たとえば「3年前のメモで、AdMob のメディエーション順序を SDK バージョン依存で決めていた理由は何だったか」を、当時の社内メモと今のコードベース両方を渡して尋ねると、「2023年版のメモではこう書いていますが、現行コードではこの前提が崩れています」というふうに矛盾点だけ抽出してくれます。
これは Claude や ChatGPT でも近いことはできますが、コンテキストを切らずに過去資料を一気に持たせられるのは、今のところ Gemini 2.5 Pro が最も自然に感じました。1M トークンの本領は、検索ではなく「過去の自分との対話」にあるのかもしれません。
向かない作業 1 : 厳密な事実回答が必要なリサーチ
ここからは正直に書きます。1M に頼り切ると痛い目を見る作業もありました。
最初に失敗したのは、「展示応募の締切一覧を、応募要項PDFを30本まとめて読んで整理してください」というタスクです。Pro は綺麗な表を返してくれましたが、よく確かめると、締切日が1〜2件、誤って隣の項目とずれていました。長文をひとなで読み切るときの「ふっと飛ばし読みする癖」のようなものが、人間と同じくたまに出るのです。
このタイプの作業は、結局短文に分けて、PDF単位で精度確認しながら処理する方が早く、安全でした。長文コンテキストは「俯瞰」には向きますが、「行単位の厳密抽出」には向きません。
向かない作業 2 : 小さく速いやり取り
当たり前のことに気づくのに時間がかかりました。短い質問に長文の状態保持はいらない、ということです。
「この関数名を3パターン提案して」みたいなときに、つい大きなコンテキストを持たせたまま聞きそうになります。レスポンスは正確に来ますが、応答時間が体感で 3〜4 倍になります。料金にも跳ねます。2.5 Flash や、状況によってはコンテキストを意図的に短く切って Pro に投げる方が、生産性は高いと2ヶ月で学びました。
向かない作業 3 : 機密度の高いコンテキスト
これは技術というより運用判断ですが、念のため書いておきます。1M に何でも入れたくなる癖がついてくると、未公開アプリの企画書や、共同制作中のアート作品の構想メモまで投げ込みたくなる瞬間があります。
私は API モードで、Google Cloud の利用規約に従って扱う範囲に絞るようにしました。「便利だから」を理由に機密の閾値を下げないことは、長く個人事業を続けるための地味な信用コストです。1M の便利さに引きずられそうになる自分への、自己注意です。
2ヶ月でわかった「使い分けの目安」
最後に、自分なりの線引きを残します。
「全体の傾向を一度に見たい」「過去の自分との対話を再開したい」「散らかった長文を整理したい」 — このときは 1M を惜しまず使います。読書を頼んでいる感覚に近く、ここに払うお金は概ね納得感があります。
逆に、「厳密な数値抽出」「短い反復タスク」「機密度の高い情報」 — このときはコンテキストを意図的に短くするか、Flash に切り替えるか、そもそも投げないかを判断します。便利な道具ほど、使わない決断のほうが効いてくるのを感じています。
派手な新機能の話よりも、こうやって「使う・使わない」の境目を地味に書き残したテキストの方が、後から自分や誰かの役に立つのかもしれません。少なくとも、12年分のメモを整理しながら、私はそんなことを考えていました。
これから1ヶ月は、整理し終えたメモを Embedding して、長文コンテキストに頼らず短文LLMで日次回せる運用に落とすつもりです。1M は「整理の瞬間」に効くのであって、毎日使い続けるものではない、というのが今の暫定的な結論です。
お読みいただきありがとうございました。同じように個人で長く続けている方の、何かしらの判断材料になれば嬉しいです。