私がCLIを勧める理由　コンテキストを制する者がAIを支配する：及川卓也からエージェント時代の開発者たちへ（5）（1/3 ページ）

生成AIでは「Claude Code」「Gemini CLI」「Codex CLI」といったCLIツールを使うことをお勧めします。CLIツールの真価は、チャットbotを利用した場合のようなブラックボックス化を避け、コンテキストを完全にコントロールできることにあります。これにより、出力の品質を劇的に向上できます。

» 2026年02月25日 05時00分公開

[及川卓也，Tably株式会社]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　2025年2月、元Tesla AIディレクターで、OpenAIの創設メンバーの一人でもあるアンドレイ・カーパシー（Andrej Karpathy）氏が「バイブコーディング」という言葉を生み出しました。LLMに任せきりでコードを書く、差分も読まない、エラーが出たらそのままコピペする。「コードが存在することすら忘れる」スタイルです。週末のプロトタイプなら悪くない。カーパシー氏自身、「コードは突然、無料で、一時的で、使い捨て可能になった」と述べています。

　この言葉は瞬く間に広まりました。そしてバイブコーディングは、コーディング以外の領域にも浸透しつつあります。AIに丸投げで文章を書く。AIの提案をそのまま採用する。AIの出力を確認せずにコピペする。

　便利です。しかし、その便利さの代償として、何かが失われていないでしょうか。

プロンプトエンジニアリングからコンテキストエンジニアリングへ

　生成AIを使いこなすための技術として「プロンプトエンジニアリング」が語られてきました。魔法の呪文を見つければ、AIは期待通りの出力を返してくれる。そんなイメージです。

　しかし2025年以降、別の言葉が浮上しています。「コンテキストエンジニアリング」です。

　カーパシー氏は同年6月、Xでこう述べました。「人々は『プロンプト』という言葉を、日常的にLLMに与える短いタスク記述と結びつける。しかし産業レベルのLLMアプリでは、コンテキストエンジニアリングこそが、次のステップに必要な情報をコンテキストウィンドウに適切に詰め込む繊細な技術であり科学だ」。

　Anthropicのエンジニアリングブログも、同じ方向を指しています。「コンテキストエンジニアリングとは、LLM推論時に最適なトークンの集合を選別し、維持するための戦略の集合である」。

　つまり、LLMの性能を引き出す鍵は、プロンプトの文言を磨くことだけではないのです。コンテキストウィンドウに何を入れ、何を入れないかを設計することにあります。

　これは、大規模言語モデル（LLM）が一度に処理できる情報量、すなわち「コンテキストウィンドウ」に上限があるために生じます。例えば、現在主流となっている代表的なモデルでも、その上限は概ね最大100万トークン程度に設定されています。この制限を超えて情報を与えると、LLMは古い情報を忘れたり、混乱をきたしたりして、望んだ応答を返さなくなる可能性があります。

　例えば、次のようなことが起こり得ます。

長い会議の議事録の要約　議事録全体をプロンプトに入れると、コンテキストウィンドウの上限を超えてしまい、モデルは要約に必要な全ての情報を参照できなくなります。その結果、要約が不完全になったり、重要な論点が漏れたりします。

大規模なコードベースの理解　関連するファイル全体を一度に読み込ませようとすると、制限を超過します。特定の関数やクラスに関する質問に対して、モデルは必要なコンテキスト（関連コード）の一部しか見られず、正確な回答やデバッグ支援ができなくなります。

　従って開発者は、質問に関連する情報のみを厳選し、コンテキストウィンドウに「何を入れ、何を入れないか」を戦略的に設計する必要があるのです。

　この視点に立つと、生成AIの使い方は根本的に変わります。そして、CLIという選択肢が浮上してきます。