AIはなぜ専用ツールを無視してシェルを使うのか｜ls・grep禁止とPure Rust化で7倍速化した実証録
作成日:

AIはなぜ専用ツールを無視してシェルを使うのか｜ls・grep禁止とPure Rust化で7倍速化した実証録

📂 検証録#Antigravity#Gemini 4 Argon#Rust#自動化#高速化#macOS#AI開発
論旨

AI エディタ（Antigravity / Cursor / VS Code 等）には、ファイルを直接読む read_file や高速検索を行う grep_search、親フォルダごと一発で書き出す write_file といった専用ネイティブツールが最初から備わっています。それにもかかわらず、AI の思考ログを観察していると わざわざ専用ツールを無視してターミナル（zsh / bash）を立ち上げ、ls・cat・grep・awk・事前の mkdir といったシェルコマンドを何十回も連発してしまう現象 に出くわします。

結論からお伝えすると、AI がシェルを使いたがるのは単なる気まぐれではなく、①事前学習データに刻まれた「UNIX ワンライナーの手癖バイアス」、②ネイティブツールだけでは画像寸法や巨大 XML を扱えない「機能の空白地帯」、③全体像が見えないまま小刻みに確認を繰り返す「推論往復税（Round-Trip Tax）」 という 3 つの構造原因によるものです。

本記事では、シェルスクリプト自動並列化研究『PaSh』のアプローチでもこの遅延が解消しない理由を解き明かしたうえで、当サイト（現在公開650記事・ルール規模 1,259行 / 約484KB）で実施した 「5 分類のシェル乱用禁止規定」×「単一 Pure Rust バイナリへのメディア・XML 処理統合」 の全貌を公開します。実機写真フォルダからレビュー記事を起こす実務において、1 記事あたり 32.1 分かかっていた作業時間が約 4.6 分（約 7.0 倍速・推論ステップ約 90% 削減）へ劇的に短縮され、Rust 実装の開発時間すらその場の 4 記事で即日回収した生ログ実測値 をご確認ください。

合わせて読みたい深まる関連情報
対象となる方

  • AI エディタに作業を任せていると、ターミナルで ls や grep、事前の mkdir ばかり繰り返してなかなか本題の執筆・実装に進まない と感じている方

  • ルールファイル（GEMINI.md / CLAUDE.md / .cursorrules）に「シェルを使うな」と書いたのに、少し複雑なファイル調査になると AI がまたシェルや使い捨て Python に逃げてしまう原因と対策 を知りたい方

  • 実機写真の EXIF 撮影日時確認・リサイズ WebP 変換・巨大 XML からの下書き抽出などを 外部依存ゼロの Rust バイナリ 1 本へ統合し、何倍速くなるのか実測値で見極めたい方

結論：シェル封鎖とRust統合で7倍速化した実測表

今回の検証の発端は、手元のフォルダに撮り溜めていた実機写真（38 枚）と過去の WordPress バックアップ XML から複数のレビュー記事を起こそうとした際、最上位モデル（Gemini 4 Argon）の思考ログに映っていた 「夥（おびただ）しい数のシェル起動」 でした。

記事を 1 文字も書き始める前の「どの写真が何の製品で、過去の下書きがあるか」を調べる段階だけで、AI は ls・wc・mdls・sips・30 行もの awk ワンライナー・さらに split コマンドによる一時ファイル分割まで繰り出し、調査だけで 16.9 分（37 推論ステップ・117 ツール呼び出し） を費やしていたのです。

そこで作業をいったん止め、「① 5 分類のシェル乱用禁止ルール」と「② シェルに頼る原因だったメディア・XML 処理の Pure Rust 統合」 をその場で実施したところ、直後の 4 記事連続作成フェーズで劇的な変化が記録されました。まずは /brain トランスクリプト（会話生ログ）から抽出した一次実測の比較表をご覧ください。

比較項目（実機写真レビュー作成） 改修前①：シェル併用
（11/06夜・3記事平均）		 改修前②：シェル多用
（11/07昼・単体1記事）		 改修後：シェル禁止＋Pure Rust
（11/07夕・4記事製造区間）		 改修効果（昼比）
1記事あたりのAI純稼働時間 15.1 分 / 本 32.1 分 / 本 約 4.6 分 / 本
（4本計 約18.5分）		 約 7.0 倍速
（85.6% 短縮）
1記事あたりの推論ステップ数 32.3 steps 60.0 steps 約 5.5〜6.0 steps 約 90% 削減
38枚の写真EXIF・寸法取得＋退避 mdls / sips を複数往復（数秒〜十数秒） 個別にシェル確認を反復 10.01 ミリ秒
（media-scan 1発）		 約 1,000 倍級
（1ターン完結）
旧WPのXML 3本から下書き抽出 手動検索＋切り出し awk 失敗・再試行で数分ロス 505 ミリ秒（約0.5秒）
（wp-drafts やり直し0回）		 手戻り完全ゼロ
深さ制限ファイル探索（1,226件） ls / find 出力切り詰め サブフォルダを小刻み走査 44.32 ミリ秒
（26件なら 0.40ms）		 1発で構造把握
質問するおじさん

1 記事あたり 32 分かかっとった写真レビューが、4 分半まで縮んどるんか！しかも推論ステップが 60 回から 6 回前後って、別物のエンジンに載せ替えたみたいじゃね。

解説ナビゲーター

驚くことに、AI モデル自体はまったく同じ Gemini 4 Argon なんです！変わったのは「AI にシェルで手探りさせるのをやめ、1 回のコマンドで必要な確定データをすべて返す Rust ツールへ繋ぎ直したこと」だけなんですよ。

なぜAIは専用ツールを無視してシェルを叩くのか

そもそも、AI エディタ側が安全で高速な read_file（ファイル読込）や write_file（親ディレクトリ自動生成付きの書込）、grep_search（内部で高速な ripgrep が直接動く検索）を用意しているにもかかわらず、なぜ賢いはずの最上位 AI がわざわざ遅いシェルコマンド（run_command）を選びたがるのでしょうか。

実際の行動ログをステップ単位で解剖すると、そこには AI の「怠慢」ではなく 3 つの明確な構造原因 があることがわかります。

数百万件のGitHubコードが刻んだ手癖バイアス

1 つ目の原因は、大規模言語モデル（LLM）が事前学習で浴びてきた圧倒的なデータ量の偏りです。世の中の技術記事、Stack Overflow の回答、GitHub の CI スクリプト、そして既存の AI ベンチマーク（SWE-bench 等）の学習ログには、cat file | grep ... | awk ... や mkdir -p dir && cp ... といった UNIX シェルの定型イディオムが何千万件も記録 されています。

一方で、各 AI エディタ固有のネイティブツール定義は、システムプロンプトの冒頭に JSON スキーマとして数千トークン添えられているに過ぎません。そのため、少しでも複雑な条件（「特定フォルダ配下の画像だけ調べたい」「複数ファイルをまとめて消したい」など）に直面すると、AI の確率分布はシステムプロンプトの薄い説明よりも、事前学習で深く刻み込まれた「慣れ親しんだシェル芸」へと強い重力で引き寄せられてしまう のです。

標準ツールだけでは届かない処理の空白地帯

2 つ目の原因は、さらに現実的な問題です。「シェルを使うな」とプロンプトで命じるだけでは解決しない最大の理由が、エディタ標準のネイティブツールには「絶妙に手が届かない空白地帯」があること です。

🕳️ ネイティブツールだけでは詰まる代表的な空白地帯

  • 画像バイナリのメタデータ確認 : read_file で JPEG 画像を開くと画素データそのものが視覚トークンとして読み込まれますが、「38 枚すべてのピクセル寸法・EXIF 撮影日時・縦横回転フラグだけを一覧表で知りたい」という用途には使えません。

  • 1行が数万文字に及ぶ巨大XML・ログの解析 : WordPress のエクスポート XML のように数万行・数 MB あり、かつ <title> と <wp:status>draft</wp:status> が複数行にまたがる構造化データは、単純な行単位の grep_search だけでは記事単位に紐づけて抽出できません。

  • ディレクトリ階層の俯瞰と一括画像変換 : WebP 変換や回転補正、同名ファイルの上書きを防ぎながらのアーカイブ移動などは、テキスト編集ツールだけでは完結しません。

この空白地帯にぶつかった瞬間、代替ツールを与えられていない AI は「ここはシェルで sips や awk、あるいは使い捨ての python3 ワンライナーを書くしかない！」と判断し、一度タガが外れるとそのまま通常のファイル確認まで ls や cat で済ませる連鎖が始まります。

1ミリ秒のコマンドより重い推論往復の罠

3 つ目の原因は、シェルコマンドが持つ「人間向けの対話設計」と「AI の推論コスト構造」の致命的なミスマッチです。

人間がターミナルで作業するときは、ls を打って画面を見るのに 0.1 秒もかかりません。しかし AI エージェントがシェルを 1 回叩くたびに、裏側では 「コマンド承認・サンドボックス起動 → 標準出力のテキスト化 → 数十万トークンの会話履歴と合わせたクラウド TPU への再送信 → 次の行動を考える推論（3〜8 秒）」 という巨大な往復コスト（Round-Trip Tax）が発生します。

実際の本日の前半ログ（Turn #1）でも、AI は次のような悪循環に陥っていました。

  1. シェルで ls と mdls を叩くが、件数が多くて一部しか見えず また次の推論ターンを消費 する。

  2. WordPress の XML から下書きを探そうと 30 行の awk スクリプトを即興で書くが、複数行タグと macOS 特有の濁点文字コード（NFD）に阻まれて 0 件または文字ズレになり、書き直しのためにさらに数ターンを浪費 する。

  3. 新規フォルダを作るたびに律儀に単独で mkdir -p を実行し、1 ファイルずつ小刻みに rm を呼んで 無駄なプロセス生成とターン消費を積み重ねる。

つまり、コマンド自体の実行時間がたとえ 50 ミリ秒でも、「小刻みにシェルを叩いて結果を見て考える」を 30 回繰り返せば、それだけで数分〜十数分の待ち時間と大量のトークンが溶けてしまう のです。

シェル自動並列化『PaSh』では解決しない理由

ここでシステム工学に詳しい方なら、「それなら Linux Foundation 傘下で研究されている『PaSh』のように、シェルスクリプト自体を自動でデータ並列化して高速化する仕組みを導入すればいいのでは？」 と考えられるかもしれません。

確かに、EuroSys ’21 で発表された論文（PaSh: Light-Touch Data-Parallel Shell Processing, arXiv:2007.09436）で知られる PaSh は、POSIX シェルスクリプトの抽象構文木（AST）を解析し、各コマンドの副作用特性（純粋関数か、順序依存かなど）の注釈をもとに、1 本の長いパイプラインを複数 CPU コアへ自動分割して並列実行する非常に優れたシステム研究です。

しかし、AI エージェントの作業環境において「シェルの内側を並列化するアプローチ」と「そもそもシェルを介在させず単一 Rust バイナリへ置き換えるアプローチ」を比較すると、解決している問題のレイヤーが根本的に異なります。

長大なデータ処理バッチには有効だが…

  • 1 本の確定済みシェルスクリプトで数 GB のテキストを流すバッチ処理では高い並列化効果を発揮する。

  • しかし AI が毎ターン叩くような 数ミリ秒〜数百ミリ秒の短命コマンド では、AST 解析・並列プランナー（Python 等）の起動コスト自体がオーバーヘッドになる。

  • 最大の弱点として、AI が「ls を見て考える → grep を見て考える → awk を書き直す」という クラウド推論の往復回数（Round-Trip）は 1 回も減らせず、パイプの終了コード消失リスクも残る。

起動税も推論往復もまとめて根絶

  • シェル（zsh / bash）のプロセス起動や文字列パースを一切挟まず、ネイティブツールと RAMDisk 常駐の単一機械語バイナリ（Rust） を直接呼び出す。

  • Rust 内部の std::thread::scope で 12 コア並列走査を行い、EXIF 情報・画像寸法・XML 下書き一覧などを 1 回の呼び出しで構造化レポートとして即答 する。

  • AI が「手探りで何度も試す」必要自体が消滅するため、コマンド実行時間がミリ秒化するだけでなく、最も重いクラウド推論ステップ数が最大 90% 激減する。

質問するおじさん

なるほどなぁ！高速道路の料金所（クラウド推論の往復）で毎回 5 秒ずつ止まっとるのに、料金所と料金所の間の 10 メートルだけフェラーリ（並列シェル）にしても到着時間は変わらんちゅうことか！

解説ナビゲーター

まさにその通りです！料金所を何十回もくぐる「細切れのシェル調査」そのものをなくして、最初から目的地までノンストップの直通トンネル（1 発で完結するネイティブツール＆Rust コマンド）を通してあげるのが一番効くんです。

実践①：ルールで封じた5分類のシェル禁止規定

そこで当サイトでは、まずマスター設計書（GEMINI.md 第 2.1 節）に 「シェル乱用禁止の 5 分類マッピング」 を明文化し、常時読み込まれるコアルールへ自動同期させました。

ここでのポイントは、単に「シェル禁止」と精神論を書くのではなく、「どのシェルコマンドを使いたくなったら、代わりにどの専用ツールを 1 発で呼ぶべきか」を IF-THEN 形式で 1 対 1 対応させたこと です。

やりたい作業分類 🚫 禁止したシェル操作（AIの手癖） ✅ 強制した代替ルート（ネイティブ＆Rust）
① ファイルを読む cat, head, tail, sed ネイティブ read_file（行範囲 StartLine / EndLine 指定）
② ファイルを探す ls, find, wc ネイティブ list_dir / find_by_name、または Rust gemini-gate files / 画像用 media-scan
③ 文字列を検索する シェルの grep, awk ネイティブ grep_search（内蔵 ripgrep 直結）、または Rust kb-search / XML用 wp-drafts
④ フォルダ作成 新規ファイル作成前の単独 mkdir / mkdir -p 事前作成せず write_file や convert-image --out-dir で親フォルダごと自動生成
⑤ ファイル削除・退避 1件ずつの小刻みな rm、無闇な rm -rf 複数削除は 1 回に統合し、原則 /usr/bin/trash・git rm・写真退避用 --archive-to を使用

特に効果が高かったのが ④「事前 mkdir の禁止」 と ⑤「小刻みな rm の禁止・安全な退避」 です。これまで AI は新しい記事フォルダを作る際、わざわざ 1 ターン使って mkdir -p src/content/blog/review/.../images を叩いてから次のターンで画像を変換していましたが、書き込み側で親ディレクトリを自動生成する規約に統一したことで、この無意味な 1 往復が完全にゼロになりました。

実践②：Pure Rustへ統合した4つの高速処理

続いて、AI がシェルや使い捨て Python へ逃げる言い訳になっていた「ネイティブツールの空白地帯」を埋めるため、外部クレート依存ゼロ（標準ライブラリのみ）で運用している Pure Rust 製バイナリ gemini-gate に media_ops.rs モジュールを新設し、以下の 4 つの専用サブコマンド を統合しました。

EXIF撮影日時と寸法の12コア並列10ミリ秒走査

実機写真からレビュー記事を起こす際、当サイトの規約では「記事の公開日（pubDate）に実機写真の初回撮影日（EXIF 撮影日時：JST）を設定すること」および「元画像のピクセル幅を超えて拡大しないこと」を定めています。従来はこれを調べるために macOS の mdls や sips -g pixelWidth を枚数分シェルループで回していました。

新設した media-scan サブコマンドでは、外部コマンドを一切起動せず、Rust の std::thread::scope による CPU 全コア並列スレッドで JPEG / PNG / WebP のバイナリヘッダを直接パース します。

⚡ media-scan が10ミリ秒で一括処理する中身

  • 画像寸法と回転フラグの直接抽出 : JPEG の SOF0/SOF2 セグメント、PNG の IHDR チャンク、WebP の VP8/VP8L/VP8X ヘッダを数 KB だけ読み取り、ピクセル幅・高さと EXIF Orientation（90 度・180 度・270 度回転情報）を即座に特定します。

  • EXIF 撮影日時（Tag 0x9003）の抽出 : TIFF ヘッダのビッグエンディアン（MM）・リトルエンディアン（II）両方のバイト順に対応し、DateTimeOriginal から正確な初回撮影日時を取得します。

  • 同名上書きゼロの安全な一括退避（--archive-to） : 採用しなかった見送り写真や処理済み元画像を退避フォルダへ移す際、シェルの mv のように同名ファイルを誤って上書き消失させないよう、衝突時は自動で連番サフィックスを付与して移動します。

実際に 38 枚の高解像度実機 JPEG が入ったフォルダに対して実行したところ、全 38 枚の撮影日時・寸法・回転情報の解析と一覧出力がわずか 10.01ms（約 100 分の 1 秒） で完了しました。

macOS濁点問題を超えるXML下書き0.5秒抽出

2 つ目の壁だった「旧 WordPress エクスポート XML（計 3 ファイル）からの未公開下書き発掘」では、前半のシェル調査で AI が書いた awk ワンライナーが手痛い失敗をしていました。原因は、macOS のファイルシステム（APFS 等）を経由した日本語文字列では「び」や「ぱ」といった濁音・半濁音が NFD（基底文字 ひ ＋ 結合濁点 U+3099） に分解されやすい一方、XML 内のテキストは NFC（合成済み び U+3073） で記録されているため、単純なバイト列比較では一致しないケースが生じることでした（Unicode 正規化仕様 UAX #15）。

そこで統合した wp-drafts サブコマンドでは、<item>...</item> ブロックの複数行パースと CDATA 除去に加え、外部クレートなしで動作する軽量な日本語 NFD → NFC 合成関数 を組み込みました。これにより、3 本の巨大 XML から下書き記事のタイトル・作成日・文字数・本文全文を重複排除付きで引き抜く処理が 505ms（約 0.5 秒）・やり直し 0 回 で確定するようになりました。

事前mkdirを根絶した回転補正WebP一括変換

3 つ目は、実機写真を記事用の .webp へ縮小変換する convert-image --out-dir の一括バッチ化です。

以前は 1 枚ずつコマンドを呼ぶか、シェルの for ループを書いていましたが、新仕様では IMG_2601.JPG=eyecatch.webp:r180 のように 「入力ファイル＝出力名＋任意の回転補正（:r90 / :r180 / :r270）」を 1 つのコマンドに何十枚でも並べて渡せる ようにしました。

内部では親ディレクトリを fs::create_dir_all で自動生成したあと、CPU コア数に応じた並列ワーカーが シェル（/bin/sh）を一切経由しない std::process::Command 直接起動 で画像変換を実行します。これにより、4 記事分・合計 26 枚の実機写真の回転補正＆WebP 生成が、事前 mkdir ゼロ・わずか 1 ターンの並列呼び出し（各 6〜13 秒） で一発完走しました。さらに ls / find 代替の深さ制限付き探索（gemini-gate files）も加わり、1,226 ファイルの走査が 44.32ms で片付く体制が整いました。

10msで全写真を構造化把握

media-scan が 38 枚の EXIF 撮影日・寸法・回転を 10ms で一覧化し、AI の視覚確認を最小限に絞る。

0.5秒で過去下書きを完全照合

wp-drafts が NFC 正規化付きで複数 XML から未公開下書きを一発抽出し、awk の試行錯誤を根絶する。

事前mkdirなしで並列WebP化

convert-image --out-dir が親フォルダ生成・回転補正・縮小 WebP 化を全コア並列で一気に完了させる。

4ms検問から本番公開まで直行

完成原稿を write_file で一発出力し、4ms の自動憲法ゲートを通過して本番デプロイ・実機検証へ直進する。

同一セッションで実証！開発時間も即日ペイした内訳

技術ブログでよくある疑問が、「ツールを Rust で自作して速くなったと言うけれど、その Rust コードを書いてテストしていた開発時間を含めたら、普通に作業した方が早かったのでは？」 という投資対効果（ROI）の視点です。

この疑問に 1 ビットの曖昧さもなく答えるため、本日のセッション（63a42d44）の開始から 4 記事の本番公開・Playwright ブラウザ実機検証完了までの全タイムスタンプを分解して検証しました。

📊 同一セッション内（全4記事・実機写真27枚）の時間収支と投資回収

  • フェーズA（15:37〜15:54｜シェル乱用での手探り調査） : AI 純稼働 16.9 分（37 steps / 117 tools）。まだ記事は 0 本。ここで「シェルを使っている」と気づいて方針転換を実施。

  • フェーズB（16:02〜16:44｜ルール策定＋Pure Rust約850行実装＋56件テスト合格） : AI 純稼働 約 45.7 分。5 分類のシェル禁止ルールを GEMINI.md へ永続化し、media-scan・wp-drafts・files・convert-image 一括回転機能を実装して自動回帰テスト 56 件を通過。

  • フェーズC（16:44〜17:04｜シェルゼロ体制での長文レビュー4本一気製造・公開・実機検証） : 壁時計 20.0 分のうち SFTP 転送待機を除いた AI 純稼働 約 18.5 分（1 記事あたり約 4.6 分・約 5.5〜6.0 steps） で、実機写真 27 枚付き・アフィリエイト登録・双方向リンク完備の 本番記事 4 本すべてを公開完了。

  • トータル投資回収判定（A＋B＋C 全合算） : 調査の回り道も Rust 開発時間もすべて含めたセッション合計の純稼働は約 81.1 分、すなわち 4 記事平均で 20.3 分 / 本 でした。同日昼にシェル多用で 1 記事書いたときの 32.1 分 / 本 を、ツールを開発したその場の 4 記事だけで完全に下回り（即日ペイ達成）、5 本目以降は開発コストゼロで 約 4.6 分 / 本（約 7 倍速） の純益だけを受け取れる計算になります。

質問するおじさん

工場のラインを止めて専用機械を組み立てた時間まで全部足し算しても、その日の夕方に出荷した 4 本だけで元が取れとるんか！それなら我慢して遅いシェルを使い続ける理由が 1 ミリもないわい。

解説ナビゲーター

しかも一度 Rust の単体バイナリに組み込んでテストで固めてしまえば、明日からも来月からもずっと壊れずに 10 ミリ秒で働き続けてくれますからね。「AI に毎回ワンライナーを発明させず、確定した道具を握らせる」ことのお手本のような結果になりました！

快適コスト試算と手元で再現するプロンプト

今回のように、Pure Rust の常駐バイナリや Astro のビルドキャッシュ、一時画像変換領域を SSD を傷めずに超高速で回すうえで大きな武器になっているのが、64GB の大容量メモリを活かした macOS RAMDisk（メモリ上の仮想超高速ディスク）環境 です。

一見すると 64GB メモリ搭載の Mac や増設メモリは初期投資が高く見えるかもしれません。しかし、誰かに見せるための見栄の消費とは異なり、毎日触れる開発・執筆母艦は「浮いた待ち時間」と「SSD 寿命の保護」で確実に元が取れます。仮に 64GB メモリ構成の母艦（または既存 iMac への 64GB 増設）を 5 年間（1,825 日） 毎日使うと仮定した場合の快適コストを試算（推論）してみます。

  • 推論ですが、約 3 万円前後の 64GB メモリ増設なら 5 年使用で 1 日あたり約 16 円、約 25〜30 万円クラスの 64GB 搭載 Mac 母艦でも 5 年使用（残価考慮前）で 1 日あたり約 137〜164 円（缶コーヒー 1 本程度） の投資で、毎回のビルド・画像変換・AI 検問ゲートがメモリ速度で瞬時に終わる環境が手に入ります。

  • さらに、作業そのものを 24 時間文句も言わずに並列処理してくれる最上位 AI プランと組み合わせれば、人間は「シェルを使っているな」と方向性を監督するだけで、面倒なバイナリ解析器もテストコードも AI 自身が数十分で組み上げてくれます。

現行の Apple Silicon 環境で最初から 64GB 以上の統合メモリを搭載して長く快適に使える母艦や、Intel 世代の iMac 27 インチ（2020 年モデル）を大容量メモリ化して RAMDisk 母艦に仕立てる定番パーツ、そして AI が書いた Rust コードの急所（所有権・スレッド・FFI）を読み解く手元リファレンスとしては、以下の構成が鉄板です。

Apple Mac mini（M4 Pro 等 Appleシリコン Pro系チップ・64GBユニファイドメモリ構成）

Apple Mac mini（M4 Pro 等 Appleシリコン Pro系チップ・64GBユニファイドメモリ構成）

Amazon楽天市場Yahoo!
【中古・整備済品】Apple iMac 27インチ Retina 5K (2020年モデル / Intel最終世代・メモリ自己増設対応)

【中古・整備済品】Apple iMac 27インチ Retina 5K (2020年モデル / Intel最終世代・メモリ自己増設対応)

Amazon楽天市場Yahoo!
【Intel Mac増設用】Crucial iMac 27インチ(2019/2020)・ノートPC用 メモリ DDR4-2666 SO-DIMM (16GB×2 / 32GB×2)

【Intel Mac増設用】Crucial iMac 27インチ(2019/2020)・ノートPC用 メモリ DDR4-2666 SO-DIMM (16GB×2 / 32GB×2)

Amazon楽天市場Yahoo!
オライリー・ジャパン『プログラミングRust 第2版』

オライリー・ジャパン『プログラミングRust 第2版』

Amazon楽天市場Yahoo!

最後に、ご自身の開発環境やブログ執筆環境でも「AI のシェル手癖」を診断し、ルール封鎖と専用 CLI 化を一気に進めたい方のために、必ず『Gemini 4 Argon』または同等以上の最上位推論モデル にそのまま貼り付けて使える導入プロンプトを用意しました。

📋 コピペ用：最上位AI（Gemini 4 Argon等）でシェル乱用を根絶する診断・構築プロンプト
以下の記事の設計思想と実測知見を参考にして、現在の私のワークスペースにおける「AIのシェルコマンド乱用ボトルネック」を調査・改善してください。
参考URL: https://lab.chihouzakki.com/blog/review/ai-shell-habit-ban-pure-rust-7x-speedup/

【絶対に守る進め方】
いきなりファイルを書き換えたり大量のシェルコマンドを実行せず、まずはネイティブのファイル読込・検索ツールを使って以下を調査し、改善計画を提示して私の合意を得てから実装に進んでください。

1. 現状のルールファイル（GEMINI.md / CLAUDE.md / .cursorrules 等）と直近の作業履歴を確認し、AIが専用ネイティブツールではなくシェル（cat, head, tail, sed, ls, find, grep, awk, 事前mkdir, 小刻みなrm 等）を使ってしまっているパターンを特定する。
2. 私の環境に合わせ、「①ネイティブツールへの5分類置き換えルール案」と、「②ネイティブツールだけでは手が届かずシェルや使い捨てスクリプトに逃げている処理（画像確認・ログ集計・定型変換など）を単一の高速CLIへ統合する設計案」を提示する。
3. 合意後、ルールの追記とCLIの実装・自動テスト作成までを一貫して行い、改修前後のコマンド実行時間とステップ数の削減見込みを報告する。

まとめ：シェルを速くするより起動させない設計へ

今回の検証で得られた結論を、明日から使える設計原則として 3 点にまとめます。

📌 AIエージェント高速化・シェル脱却の3原則

  • AI は放っておくと事前学習の手癖でシェルに逃げる : 専用ツールがあっても、学習データに多い ls・grep・awk・事前 mkdir を選びがちになり、コマンド実行時間以上に「結果を見てまた考えるクラウド推論の往復税」で時間を浪費します。

  • 「5分類の禁止ルール」と「空白を埋める道具」は必ずセットで渡す : ルールで禁止するだけでは画像寸法確認や巨大 XML 抽出で行き詰まるため、ネイティブツールの死角を 1 発で片付ける Pure Rust サブコマンド（EXIF 走査 10ms・XML 抽出 0.5秒・並列 WebP 変換）を同時に装備させるのが鉄則です。

  • ツール開発コストはその日のうちに回収できる : シェル手探りをやめて単一 Rust バイナリへ統合した結果、写真レビュー作成は 1 記事 32.1 分 → 約 4.6 分（約 7.0 倍速・推論ステップ約 90% 削減） へ劇的に短縮され、Rust 実装にかかった時間を含めても最初の 4 記事だけで即日ペイできました。

もし手元の AI エディタが画面の隅でカタカタと ls や mkdir を連発していたら、それは AI の能力限界ではなく「伸びしろの塊」が見つかった合図です。ぜひ一度立ち止まって、細切れのシェルパイプを 1 本の真っ直ぐな専用ツールへ置き換えてみてください。驚くほど静かで速い制作ラインに生まれ変わるはずです。

シェル手探りがなくなってスヤスヤ眠るノルウェージャンフォレストキャット