AIに提案されたツールを全部作って、もう一度測ってみた

前回の記事で、自作のAIShellを使うCodexと通常のCodexへ同じ課題を渡して比べたら、tokenが25.86%減った。効果は出そうだと思った。ただ、3課題9試行の結果なので、確信までは持てなかった。

今回は機能を増やして、ベンチマークも大きくして測り直した。結果から書くと、tokenは52.44%減まで行った。前回より上がっていて、思った以上だった。

便利そうなツールを全部作った

機能を増やすにあたって、Claudeに聞いてみた。俺の開発環境を踏まえて、どんなツールがあると便利か。何個も提案が返ってきた。

Claudeは最初、数個だけ実装して様子を見る案を勧めてきた。俺はほぼ趣味の個人開発者で、本業の裏でAIを回しているだけだから、開発した結果のリスクを考える必要がない。全部作ることにした。

いまのAIShellの機能

前回の時点であった機能は5つだった。

• 作業フォルダの現在状態と、前回からの変更をまとめて返す
• 複数のファイルから、必要な量だけ読む
• 指定された範囲を検索する
• ビルドやテストを実行し、重要な診断を返す
• 保存してある完全な出力から、必要な範囲を読む

今回増えた機能を全部並べる。

• 変化を待つ: ファイルの変化やビルドの完了を、AIShellが検知するまで待つ。待っている間、AIは確認のコマンドを打たずに済む。
• 裏で走らせて、必要な時に見る: ビルドやテストを裏で走らせたまま、AIは次の作業を進める。途中経過と結果は、必要になった時に取りに行く。
• 走らせた処理の取り消し: 裏で走らせた処理を途中で取り消して、残さず終わらせる。
• 複数ファイルをまとめて変更する: 複数ファイルの変更を一度に適用する。適用の前に、編集の前提にしたファイルの中身が変わっていないかを確認して、変わっていたら止める。
• 変更の影響範囲を出す: このファイルを変えたら、どのソースとどのテストに影響が出るかを返す。ビルドの依存記録からも影響をたどれる。たどりきれない依存は、分からないものとして報告する。
• 作業フォルダの記憶の永続化: AIShellを再起動しても前回の状態を覚えていて、止まっている間に起きた変更を差分で返す。
• ブランチとWorktreeの比較: ブランチ同士の差分や、Worktreeで起きている変更をまとめて返す。
• Gitの細かい状態の把握: ステージ済みと未ステージが混ざった状態や、ファイル名の変更を、変更の素性を保ったまま報告する。
• プロジェクト構成の記憶: このプロジェクトのビルドコマンドとテストコマンドが何か、を覚えて返す。package.jsonのような構成ファイルが変わったら覚え直す。
• 複数の検索の一括実行: 複数の検索の問い合わせを一度に受けて、変更されたファイルとテストを優先しながらまとめて返す。
• 意味での検索: 文字の一致に加えて、関数や変数のつながりをたどって探す。編集の直後は、編集前の古い解析結果を古いものとして扱う。
• 診断の整形: ビルドやテストが出す診断を、形式ごとに決まった構造へ整えて返す。形式が壊れていたら、壊れていると報告する。
• 確認結果の再利用: 同じ確認を繰り返す時、入力が変わっていなければ前回の結果を使う。入力が変わっていたら実行し直す。
• 実行すべきテストの提案: 変更の内容から、いま実行すべきテストを提案する。提案だけで止めることも、許可を待ってから実行することもできる。
• 過去の実行結果の検索と比較: 保存してある複数回の実行出力をまたいで検索する。2回の実行を比べて、増えた警告と消えた警告を出す。
• 復旧用の操作: AIShell自体の状態確認と、管理アプリを開く操作。設定が足りない時や、管理アプリからAIの操作を止めている間も、この2つだけは使える。

このうち、変化を待つ、裏で走らせて見る、まとめて変更する、影響範囲の4つは、新しいツールとして追加した。復旧用の操作も、状態確認と管理アプリを開く2本のツールになった。残りの機能は前からある5本のツールの中に入れた。AIから見えるツールの数は5本から11本になっている。

それぞれが実際にどれだけ効いたかを、この後で課題別に見ていく。

ベンチマークを32課題に増やした

課題は、実際の開発で起きる場面から32個作った。ビルドの完了を待つ、複数ファイルへ変更を当てる、過去の実行結果から原因を探す、といった内容で、それぞれを通常のCodexとAIShellへ3回ずつ渡した。成功かどうかは、課題ごとに決めた条件で機械的に判定した。

tokenは52.44%減った

全体の結果はこうなった。

成功1課題あたりのtokenは、失敗した試行に使った分も含めた合計を、3回すべて成功した課題の数で割った数字だ。前回の25.86%減より上がって、成功した課題の数も増えた。

ここから、機能ごとに何を作って、どの課題で何が起きたかを見ていく。効かなかった機能もそのまま書く。

新しいツール4本の結果

変化を待つ

通常のCodexは待っている間も確認のコマンドを打ち続けるので、その確認がすべてtokenと時間になる。AIShellは変化が起きた時に知らせる。

32課題の中で一番差が付いた機能だった。外部の編集を待つ課題でtokenが75〜78%減り、時間は9割以上短くなった。変更の通知が途切れたことを検知して、調べ直しへ切り替える課題でも68%減った。

裏で走らせて、必要な時に見る

この機能の課題は2つある。走っているビルドから最初の失敗を取り出し、終わったら終了コードを報告する課題と、走らせたプロセスを取り消して残さず終わらせる課題だ。通常のCodexは6回すべて失敗した。AIShellは6回中5回成功した。効率以前に、シェル経由ではやり切れなかった種類の作業だった。

複数ファイルをまとめて変更する

適用の前に、編集の前提にしたファイルの中身が変わっていないかを確認して、変わっていたら止める仕組みにしている。

課題は3つで、通常のCodexは9回中5回成功、AIShellは9回すべて成功した。両方が成功した課題で比べると、tokenは33〜40%減だった。

変更の影響範囲を出す

直接の依存をたどる課題は、通常のCodexが3回中0回、AIShellが3回すべて成功した。ビルドの依存記録から影響を出す課題も1回対3回で、tokenは49%減った。

AIShellが失敗した課題もここにあった。たどりきれない依存が混ざっている時に「ここから先は分からない」と報告する課題で、通常のCodexは2回成功、AIShellは3回とも失敗した。分からない部分の報告の仕方に、まだ穴がある。

前からあるツールへの拡張の結果

作業フォルダの記憶を持ち続ける

AIShellを再起動しても前回の状態を覚えていて、止まっている間に起きた変更を差分で返す。再起動後の復元でtoken 44%減、停止中の編集の検出で32%減だった。

Gitの状態把握

ブランチ同士の比較や、Worktreeの比較をツールとして持たせた。ファイル名の変更が混ざった状態の把握で63%減、Worktreeの変更把握で51%減。ステージ済みと未ステージが混ざった状態を正確に報告する課題は、通常のCodexが3回とも失敗して、AIShellは3回成功した。

プロジェクト構成の把握

このプロジェクトのビルドコマンドとテストコマンドが何か、を覚えて返す。package.jsonが変わったら覚え直す。構成変更後の把握し直しで77%減、覚えた内容をそのまま使える場面で46%減だった。

検索と読み取り

複数の検索の問い合わせをまとめて流す課題で54%減った。関数や変数のつながりをたどって探す検索は、編集直後に古い解析結果をそのまま出さないことまで含めて課題にしていて、通常のCodexは6回中0回、AIShellは5回成功した。

ここにも失敗はある。決めた量に収まる分だけ読んで残りを続きとして返す課題は、どちらも3回とも失敗した。

ビルドとテストの実行まわり

実行結果の診断を決まった形へ整える課題は、成功が1回対2回で、tokenは42%少なかった。変更に対して実行すべきテストを提案し、許可を待ってから実行する課題は、通常のCodexが6回中0回、AIShellが5回成功した。

効かなかった課題もここに集まっている。わざと形式を壊した診断データを壊れていると判定させる課題では、通常のCodexより3割多くtokenを使った。同じ確認を繰り返す時に前回の結果を再利用する機能は、tokenの差がほぼ出なかった。すでに手元にある情報を扱う場面では、AIShellを経由する分の上乗せが残る。

過去の実行結果の検索

AIShellは実行の完全な出力を保存している。複数回の実行をまたいでエラーを検索する課題で48%減、2回の実行結果を比べて増えた警告と消えた警告を出す課題で46%減だった。通常のCodexは、もう一度実行して出力を作り直すところから始めるので、この差になる。

前回の問いの続き

前回の記事は、「AIならシェルもターミナルもいらなくね？」という疑問から始めた。

今回の結果では、シェルを通さない接続の方が、tokenも時間も少なく、成功した課題も多かった。少なくともこのベンチマークの範囲では、AIはシェルを使わない方が良い結果を出している。

次は、普段の開発で同じ効果が出るかを確かめていく。