Claude Code実践者が見た、AI開発におけるCLIツールと手順書の現在地

AIに自律的な作業を任せる開発手法が急速に普及している。

1年で20個以上のAI連携ツールを生み出す開発者も現れた。

まあ、大半は誰にも使われない自己満足の産物だが。

彼らが注力しているのは、プロンプトの調整ではない。

AIが使うための「道具」の開発だ。

しかし、AI専用の連携規格であるMCPには大きな落とし穴があった。

現場の最適解は、昔ながらのCLIと自然言語の手順書の組み合わせに回帰している。

複数の情報源から得られた統合知見（crossSourceFindings）として、このトレンドを紐解く。

最新AI開発トレンドの全体像

AI開発の主戦場が完全に移行した。

これまでは、いかに賢いプロンプトを書くかが勝負だった。

今は違う。

最高峰のAIモデルをそのまま借りて、AIに自社システムを操作させる「手足」を作るフェーズに入っている。

AIは確率的予測マシンだ。

一般的な知識は豊富だが、個別のプロジェクトの独自仕様は知らない。

文脈を与えなければ、もっともらしい嘘をつく。

このハルシネーションを防ぐため、RAGやReActといった技術が標準化された。

AIに「推論」と「行動」を交互に行わせる。

自律的に計画を立て、外部ツールを使って情報を集め、タスクを実行させる。

この流れの中で、AIに外部ツールを使わせる技術が急速に進化している。

かつてはプログラム内に直接機能を書き込む必要があった。

現在は、プラグインのようにAIとツールを繋ぐ共通規格が注目を集めている。

MCP（Model Context Protocol）の登場だ。

多くの企業がMCPサーバーの開発に乗り出した。

AIにSlackを操作させたり、データベースを検索させたりするための専用インターフェースだ。

しかし、ここで実務上の巨大な壁にぶつかっている。

MCPはAIが使うことを前提に設計されている。

人間が直接コマンドを叩いて動作確認することが極めて困難だ。

専用のクライアントツールを用意しなければテストすらできない。

開発とデバッグのハードルが高すぎた。

ここで、海外の開発者コミュニティから全く別のアプローチが提示された。

それが「CLI + Skills」という手法だ。

人間がターミナルで実行できる通常のCLIツールを作る。

そのツールの使い方を、自然言語の「Skill（手順書）」としてAIに渡す。

AIは手順書を読み、ターミナル上でCLIコマンドを実行する。

この手法なら、人間は慣れ親しんだ方法でツールのテストと保守ができる。

AI専用の複雑なサーバーを構築する必要はない。

同時に、AIに渡す「文脈」の作り方にも変化が起きている。

コードの変更をAIにレビューさせる際、単なる差分を渡すだけでは不十分だ。

コミットごとの流れや、最終的な変更内容との対応が追いづらい。

そこで、Gitのブランチ差分とコミット履歴を1つのXMLファイルにまとめるツールが登場した。

人間が読むための画面ではなく、AIがパースしやすい構造化データを出力する。

AIに情報を渡すための専用の変換器だ。

さらに、AIの自律実行における安全性の担保も必須の課題となっている。

AIにすべてを任せるのは危険だ。

不可逆な操作を行う前に、必ず人間の承認を挟むゲートウェイツールが開発されている。

AIと一緒に働くためのインフラ構築が、現在の個人開発やOSS活動の最前線になっている。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

開発者目線の核心解説

Claude Codeで毎日コードを書いている身として、この流れは納得できる。

僕らの仕事は「コードを書くこと」から「AIが働きやすい環境を整えること」に変わった。

MCPの理念は理解できる。

すべてのAIモデルが共通の規格で外部ツールと通信できる世界だ。

しかし、開発現場はもっと泥臭い。

ツールを作る上で一番時間がかかるのは、実装ではなくテストとデバッグだ。

MCPサーバーを作ると、このテストのサイクルが10倍遅くなる。

人間がサクッと動かして結果を確認できない。

CI/CDパイプラインに組み込んで自動テストを回すのも一苦労になる。

だからこそ「CLI + Skills」のアプローチが圧倒的に強い。

CLIは人間が使うために作られたインターフェースだ。

標準入力と標準出力がある。

オプション引数を渡して挙動を変えられる。

シェルスクリプトで他のツールと簡単に繋げる。

Unix哲学そのものだ。

人間がターミナルで叩いて正常に動くことを確認する。

既存のテストフレームワークを使って単体テストを書く。

ここまでは従来のソフトウェア開発と全く同じだ。

違うのはその先だ。

このCLIの使い方を、Markdownなどの自然言語でドキュメント化する。

「このコマンドは〇〇をするためのものです。引数には〇〇を指定してください。」

これがSkill（手順書）になる。

Claude Codeの機能にも、まさにこの仕組みが組み込まれている。

AIに手順書を読み込ませるだけで、AIはターミナルを操作して自律的にタスクを進める。

複雑な連携プロトコルは一切不要だ。

しんたろー：
MCPの仕様を見たとき、直感で「これ保守するのキツそう」と思った。
AI専用の口を別に作るのは、二重管理の温床になる。
やっぱり人間が叩けるコマンドラインが一番安心するんだよな。

AIに情報を渡すフォーマットの最適化も求められる。

LLMの心臓部であるTransformerアーキテクチャには構造的な弱点がある。

入力されたトークン（単語）の関連性を総当たりで計算するため、計算量がトークン数の2乗に比例して増大する。

無駄な情報を渡せば渡すほど、処理が重くなり、精度も落ちる。

だから、リポジトリ全体をそのままAIに投げつけるのは悪手だ。

必要な情報だけを抽出して渡す必要がある。

Gitの差分を1ファイルのXMLにまとめるアプローチは非常に合理的だ。

AIは自然言語だけでなく、XMLやJSONといった構造化データの解析が得意だ。

タグで囲まれた情報を正確に抽出し、文脈を理解する。

差分だけでなく、コミットメッセージや作成者の情報も含める。

「なぜその変更が行われたのか」という意図がAIに伝わる。

これにより、AIのコードレビューの精度は80%向上する。

ここで「承認ゲート」の存在が浮上する。

AIの性能が上がれば上がるほど、自律的にできることが増える。

コードを書き、テストを回し、そのまま本番環境にデプロイすることも可能だ。

しかし、それを無条件で許可してはいけない。

リリース作業。

データベースのマイグレーション。

Pull Requestのマージ。

Slackの全体チャンネルへの通知。

これらはすべて不可逆な操作だ。

失敗したときのダメージが大きすぎる。

ここで必要になるのが、Human-in-the-loop（人間の介入）の設計だ。

AIがコマンドを実行しようとしたとき、ターミナル上で処理を一時停止する。

「この操作を実行してもよろしいですか？ [Y/n]」

人間が確認し、承認したときだけ先に進む。

この小さなゲートウェイを挟むだけで、AIの暴走リスクはゼロになる。

利便性と安全性の完璧なバランスだ。

実務への影響と具体的なアクション

日々の開発への取り入れ方を考える。

ゼロから巨大なAIシステムを構築する必要はない。

今ある資産をそのまま活かしながら、少しずつAIにタスクを委譲していく。

まずは、日常的に行っている定型作業を小さなCLIツールにする。

あるいは、既存のシェルスクリプトを整理する。

1つのツールには1つの機能だけを持たせる。

小さく作って組み合わせる。

次に、そのツールの「取扱説明書」を書く。

人間向けではなく、AI向けに書く。

前提条件、必要な引数、エラー時の対処法を明確に言語化する。

これをプロジェクトのルートディレクトリに配置する。

Claude CodeのようなAIアシスタントに、その手順書を読ませる。

「この手順書に従って、リリース作業を準備して」と指示を出す。

AIは手順書を理解し、人間が作ったCLIツールを正確に実行する。

しんたろー：
自動化のスクリプトって、結局自分が使い方を忘れるんだよね。
AI向けに手順書を書くことは、未来の自分へのドキュメントにもなる。
一石二鳥のプラクティスだ。

AIにコードの文脈を渡す仕組みも整備する。

レビューやリファクタリングを依頼する際、単にファイルを開かせるだけでは不十分だ。

関連するファイルの履歴や変更の意図をまとめたデータを用意する。

前述のGit履歴をXML化するようなツールを導入するか、自作する。

AIに渡す情報は、常に「構造化」と「集約」を意識する。

バラバラのファイルを複数読ませるより、1ファイルにまとめたほうがAIの理解度は高い。

これはプロンプトエンジニアリングの基本だ。

そして、自動化のフローには一時停止ポイントを設ける。

破壊的な操作を行うスクリプトには、標準入力待ちの処理を追加する。

AIがそのスクリプトを実行すると、ターミナル上で人間の入力を待つ状態になる。

人間が内容を確認し、エンターキーを押すまで処理は進まない。

この「確認付き自動化」は、精神的な安心感が全く違う。

AIを完全に信用するのではなく、優秀な部下として扱う。

最終責任は人間が持つ。

このスタンスが、現在のAI活用における一つの解だ。

ツールの配布方法も問われる。

チーム内でツールを共有する場合、環境構築の手間は最小限にしたい。

Go言語などでシングルバイナリとしてビルドし、パッケージマネージャーで一発インストールできるようにする。

ユーザーに言語のランタイムを要求しない設計にする。

僕らの仕事は、AIという新しい同僚のために、働きやすいオフィスを設計することだ。

適切な道具を渡し、わかりやすいマニュアルを用意し、危険な場所には柵を設ける。

この環境整備が、これからの開発者のコアスキルになる。

FAQ

Q1: MCPと「CLI + Skills」の違いは何ですか？

MCP（Model Context Protocol）はAIとツールを直接繋ぐための標準規格です。

AI前提の設計であるため、人間による単体テストやデバッグが難しいという実務上の課題があります。

一方「CLI + Skills」は、人間がターミナルで実行・テストできる通常のCLIツールを作成し、その使い方を自然言語（Skill）でAIに教える手法です。

開発者は慣れ親しんだ方法でツールを保守しつつ、AIに機能を提供できるため、現在の現場でのベストプラクティスとなっています。

Q2: AIにCLIツールを使わせる際、暴走を防ぐには？

完全に全自動化するのではなく「確認付き（Human-in-the-loop）」の設計にすることが必須です。

例えば、本番環境へのデプロイやデータベースの更新、PRのマージなど不可逆な操作を行うCLIツールの内部に、必ずプロンプトを出して人間の入力を待つ処理を組み込みます。

AIがコマンドを実行しても、最終的な承認を人間が行うゲートウェイを挟むことで、AIの利便性を活かしつつ安全性を完全に担保できます。

Q3: AIにコードベースやGit履歴を理解させるコツは？

AIがパースしやすい形式（XMLやJSONなど）に情報を1ファイルにまとめて渡すのが最も効果的です。

単なるコードの差分だけでなく、コミットメッセージやファイルの変更履歴など「文脈」を含めることで、AIのレビュー精度やコード理解度が80%向上します。

LLMの特性上、複数のファイルを行き来させるよりも、構造化された単一のドキュメントを読み込ませる方が、計算負荷も下がりハルシネーションも防げます。

まとめ

AIにツールを使わせるなら、複雑な専用サーバーを作るより、使い慣れたCLIと手順書の組み合わせが一番確実で安全だ。

しんたろー：
ThreadPostのデプロイ周りも、このCLI+手順書方式で組み直すのが良さそうだ。
複雑な連携を頑張るより、シンプルなコマンドをAIに叩かせる方が圧倒的にメンテが楽なんだよな。

👉 ThreadPostでSNS運用を自動化する