T52_Claude CodeにCLIを持たせたら、直す回数が激減した

AIの「完了しました」を、そのまま信じたことは一度もない。

だから毎回、PowerPointを開いて、はみ出しや崩れがないか自分の目で確認している。

ただ、直すところが、ほとんどなくなった。

「完了しました」を、毎回自分の目で確認している

Claude CodeやCodexに資料作成を任せて、「完了しました」の報告。

最終確認はいつも自分の目。ここは、今も変えていません。

変わったのは、確認したあとの話です。直すところがほとんど見つかりません。

何が変わったのか——答えは、AIモデルではありませんでした。

AIエージェントの実力は、モデルだけでは決まらない

Claude CodeやCodexを使い始めると、まずAIモデルの性能に目が向きます。

どのモデルを使うか、どう指示を書くか、CLAUDE.mdやAGENTS.mdに何を書くか——考えることは尽きません。

もちろん、どれも大事です。ただ、それだけでは足りませんでした。

Grep、Read、Grepと、AIの手が止まらない。

作成したWordは、余白と装飾でノイズだらけ。

仕上がったPowerPointは、文字が枠からはみ出していた。

こうした問題は、AIの「考える力」ではなく、AIが使える「道具」の側にありました。

頭脳と手足 — CLIツールという発想

Claude CodeやCodexは、ターミナル上でコマンドを実行できます。つまり、PCに入っているCLIツールを、そのまま呼び出せるということです。

CLIとは、文字で命令してソフトウェアを動かす仕組み。検索、変換、画像化——こうした処理を、決まったコマンドで実行できます。

Claude CodeやCodexが頭脳だとすれば、CLIツールは手足です。

頭がよくても、道具が少なければ、できる仕事は限られます。用途に合った道具を渡せば、同じモデルでも仕事の進み方が変わります。

私が実際に使っているCLIの中から、象徴的な3つを紹介します。

手足その1：PowerPointを検査するCLI群

Codexに資料作成を任せると、PPTXファイルが出てきます。ただ、ファイルが生成されたことと、スライドが正しく表示されることは、違います。

以前は、この違いを自分の目だけで埋めていました。開く、確認、崩れの発見、修正依頼、再確認——この繰り返しでした。

今は、PowerPointを一度PDFに変換し、さらに画像に変換してから、AI自身が見た目を確認する流れを組んでいます。使うのは`libreoffice-qa`でPDF化し、`pdftoppm`で各ページを画像にする、という数個のCLIだけです。

AIが自分で崩れに気づき、直してから報告してきます。だから、私が開いたときには、直すところがほとんど残っていません。

確認する習慣は変えていませんが、確認のたびに手を動かす回数は、目に見えて減りました。

手足その2：文書をAIが読める形に変えるPandoc

Word文書には、フォント、余白、図形、コメント、変更履歴。文章以外の情報が、たくさん含まれています。

`Pandoc`は、WordやHTMLをMarkdownへ変換するCLIツールです。装飾を取り除き、骨格だけを残します。

Wordのままでも、AIは何とか読み込んで作業してくれます。ただ、単に一度読ませるだけならそれで十分ですが、何度も修正し、比較し、繰り返し使う資料は話が変わります。

AIで採点したところ、テキスト抽出の確実性、コンテキスト効率、差分管理のしやすさの3点で、Markdownはおよそ91点、Wordはおよそ72点でした。

「第3章だけ要約して」と場所を正確に指定できるのも、差分がひと目で分かるのも、Markdownならではです。

一方、表やページ配置まで見せたいなら、Wordが有利です。だから私は、文章の意味を扱う段階はMarkdown、最後の仕上げはWord、と二段構成にしています。

手足その3：コードの地図を作るGraphify

私自身まだ使い込んでいない話です。

`Graphify`は、コードの構造をあらかじめ解析し、関数やクラス、呼び出し関係を地図のように扱えるツールだと理解しています。

Graphifyがない場合、Claude CodeはGrepとReadで手探りするしかありません。地図なしで、巨大な建物を部屋ごと探しているような状態です。

先に地図を渡しておけば、探索コストを減らせるはずです。コンテキストの消費を抑え、体感の速度も上げられると期待しています。

ただし、これはコードや設定ファイルのように、構造を持つプロジェクトに効く話です。
文書や画像が溜まっているだけのプロジェクトには、同じ効果は期待できません。

便利な手足には、ブレーキも必要

CLIは、文字で命令できる分、危険な操作も簡単に実行できてしまいます。だから私は、CLI操作を3つに分けています。

確認なしで進めてよい操作。実行前に必ず確認する操作。原則実行させない操作。

線引きは、ツール単位ではなく操作単位です。同じGitでも、差分を見るのは自由ですが、GitHubへの反映は確認が必要です。

「鵜呑みにしない」を、より賢くやる方法

確認は、今も欠かしていません。減ったのは、直す作業のほうです。

CLIツールは、AIに前捌きをさせる仕組みです。探す、変換する、検査する——この部分をAI自身に任せておくと、人間が確認したときに、直すべきところがそもそも少なくなります。

すべてのCLIを入れる必要はありません。自分の作業で、AIが何度もつまずいている場所を探します。そこに使えるCLIがないか調べます。小さく試して、効果があれば手順に組み込みます。この順番で十分です。

あなたが、AIの「完了しました」を確認したとき、どのくらいの手直しがありますか。

人生の限りある時間を大切に。シンパクト和 でした。
最後までお読みいただき、ありがとうございます。
スキやコメントをいただけると励みになります。