「starship.toml が仕様書になる」〜自分だけのツールを LLM で作って手に馴染ませていった話

最終更新日： 2026年08月17日投稿日： 2026年08月19日

はじめに

AI インテグレーションユニットの松本です。これはヌーラボブログリレー2026 夏の3日目の記事です。

コーディングエージェントのおかげで、ちょっとしたツールなら「書いてもらう」ことが現実的になりました。それによって、誰かが作った多機能ツールを導入して設定をカスタマイズして使う代わりに、自分に必要な機能だけを持つツールを一から作って使う、という選択肢が出てきたのではないかと個人的には思っています。

私もこの1年ほどで、Claude Code のステータス行を表示する ccr、Zed をフォークして作っているコーディングエージェント作業用ターミナル agentium (これはまだ作りかけです)、シェルプロンプト表示の zprompt と、いくつか自分専用のツールを作ってきました。この記事では、このうち一番小さい zprompt を実例に、既存ツールの設定ファイルを仕様書として Claude Code に渡してツールを作り、手に馴染ませていった過程を紹介します。

Starship を置き換えたくなる

それまで、私はシェルのプロンプト表示に Starship を使っていましたが、大規模なリポジトリではプロンプトの表示が遅いことが気になっていました。タイムアウトは設定できるものの、間に合わなかった情報は表示されなくなるので、それはそれで困ります。

設定などを見直すことも検討しましたが、Starship の設定の豊富さに比べて自分が実際に使っている機能の少なさを考えると、必要な機能だけをコーディングエージェントに書いてもらったほうが軽量なツールができて、さらにはカスタマイズの余地が広がるのでよいのではないか、と思うようになりました。

starship.toml を渡して、できるか聞いてみる

Starshipで自分が使っている機能を伝えるために設定ファイル starship.toml をディレクトリにコピーした上で、Claude Code に次のようなプロンプトで調査させてみました (原文ママ、一部抜粋、「懸念実行」は「懸念事項」の誤字):

zig を使って https://starship.rs/ のようなzshプロンプト出力アプリを作ることはできるか調査してください

やりたいこと

@starship.toml 相当の機能が実現できること

git のステータスの表示のための、情報取得にはziggitを使う (今使える状態のはずなので必要なら試してください)

ステータス表示のためにそれぞれの情報をスレッドなどで並列化 (n秒以上遅延したらキャンセル)

プロンプトで自作の専用アプリを作る理由

コンパイルしたバイナリがカスタマイズできる必要はない

今ならソースから作って、必要ならLLMに修正を依頼したほうがよい

zigを使う理由

バイナリを可能なかぎり小さくしたい

それでいて実行速度も保ちたい

懸念実行: 並列実行のための手段が乏しそう

ziggit は Zig で書かれた git コマンドです (使えそうだと思って指定していましたが結局使いませんでした)。

この後は ziggit のリポジトリの調査と、提案された方法をベースに開発計画を立てるように指示しただけです。そして最初のプロンプトから59分48秒後には、Starship のときと同じように時刻・ディレクトリ・git ブランチ・ステータス・コマンド実行時間が表示される、動くバイナリができていました。

この1時間で、エージェントは zig build のエラーを2回自分で直し、git リポジトリのあるディレクトリとそうではないディレクトリの両方でバイナリを実行して git 情報の出し分けを確認し、検証用のテストコミットまで自分で作り、最後には hyperfine で Starship との比較ベンチマークまで走らせていました。今回のような「実行するとテキストを1行吐いて終わる」CLI は出力のすべてがテキストなので、エージェントが自分で実行して結果を確かめて直す、というループが上手く回りました。

自分だけのツールの強み

カスタマイズの割りきり

自分だけのツールは自分に100%フィットしているのでカスタマイズの必要はなく、実行時に設定したい場合は引数や環境変数を使えばよいので設定ファイルは必要ないはずです。

そこで、zprompt では設定ファイルをなくすことで、設定項目に関するコード (ファイルのパース処理や条件分岐) とドキュメント (フラグの説明やデフォルト値など) が不要になりました。

色もセグメントの構成もすべてソースコードに直書きしており、必要ならコードを書き換えてバイナリを作り直せばよいという割りきりです。

機能の割りきり

言語のバージョン表示は個人的に気にする機会が多かった Python と Node.js の2つに絞りました。
また、AWS SSO セッションの残り時間のような、業務に必要な表示も入れています。
自分だけが使うので「24時間表示で日付は不要」といった割りきりです。

設計の割りきり

zprompt は確保したメモリを一切解放せずに終了しますし (1回起動して1行出力して終わるツールなので問題になりません)、情報収集の 800ms のデッドラインを超過したときは各処理をキャンセルするのではなくプロセスごと exit します (死んだネットワークマウントの上で固まった処理は、キャンセルを待っても戻ってこないためです)。

実行環境の割りきり

「自分が使っている環境で動けば OK」と割りきることでコードをシンプルに保つことができます。

手に馴染ませていく

ひとまず使える状態になってからは、使って気になったところをその場で Claude Code で改善していきました。以下に示したもの以外に、HEAD にある git のタグの数を 🏷️(9) のように表示する、といった細かい修正も行っています。

worktree をハイライトする

私は git worktree をリポジトリ内の .worktrees/ ディレクトリ配下に切る運用をしているので、プロンプトのパス表示では、見たい情報であるリポジトリ名と worktree 名を白、間のパスを灰色に表示させています。個人の運用にべったり依存した機能ですが、自分専用ツールなら気兼ねなく入れられます。Starship の設定だけでは実現が難しいので、個人的にかなり嬉しい機能です。

サブプロセスでの処理をやめたら高速化できると期待した話

プロンプト表示では HEAD を指すタグの情報をサブプロセスで取得していたので、これをプロセス内で処理させると速くなるかもと思ってコーディングエージェントに依頼しました。

できたものは .git/refs/tags と packed-refs を自前でパースし、annotated tag についてはオブジェクトファイルを zlib 展開して中身を読む、という実装で、軽く試した範囲では速くなったのですが、大きなリポジトリでプロンプトがタイムアウトするようになってしまい、結局元に戻しました。残念な結果になりましたが、着手から撤退まで1日で済んだので、思いつきの最適化も気軽に試すことができます。

プロンプトを遅延更新する

これが私にとって「顧客が本当に必要だったもの」でした。

現在の zprompt では、これを zle -F という「ファイルディスクリプタ (FD) を監視して、読めるようになったらコールバック関数を呼ぶ」機構で実現しています。大雑把には次のようなコードになります。

PROMPT="$($_zp_bin --exit-code=$ec --duration=$dur --deadline=0)"  # 軽量版を実行
exec {_zp_fd}&lt; &lt;($_zp_bin --no-deadline ...)  # フル版 zprompt (_zp_bin) をバックグラウンドで計算
zle -F $_zp_fd _zp_cb                         # FD が読めるようになったらプロンプトを更新するコールバックを実行

_zp_cb() {
  zle reset-prompt;   # 実際には FD からこれ以上データが来なくなったら実行させている
}

zprompt の軽量版を同期モードで呼んで即座にプロンプトを表示させつつバックグラウンドでフル処理版を実行させておき、それが完了したら zle reset-prompt で描き直すようにしています (この zsh 側の仕組み自体は Starship でも使えるはずです)。

シェルごと作りかけてやめる

実はこの zle -F に辿り着く前、プロンプトの遅延更新は zprompt のような外部コマンド方式では不可能だと考えていました。プロンプト文字列を標準出力に返した時点でプロセスは終了しているので、後から書き換える手段がないと思っていたのです。

ラインエディタ部分に特化した簡易シェルを自作するしかないとまで考えていたのですが、そのための調査を進めていくうちに、zle -F を使う案をコーディングエージェントが出してきました。それによって、シェルの自作という重い工事に踏み込む前に「やらない」と判断して zprompt の改変に着手することができました。

おわりに

starship.toml を仕様書にして自分専用のプロンプトツールを作った経緯を紹介しました。私の環境での計測では現在の zprompt はファイルサイズ 197KB・平均実行時間 29.4ms で、Starship の 8.2MB・41.1ms と比べれば小さくて速い状態を維持できています。

これからも当然、他人が作ったいろいろなツールを使い続けていくとは思いますが、今回の体験を通して、自分に特化したツールを作ってそれをカスタマイズしていく、ということも有力な選択肢になっていくのではないかと個人的には思えました。「自分だけのツール」では他の人からの要望は来ないので、.zshrc などを改変するのと同じように、自分のやる気が出たときにソースコードを改変していけばよいのです。

今回のプロジェクトでは、starship.toml で内容が把握できる上に出力がテキスト1行の CLI なのでエージェントが自分で実行して確かめるループが作りやすい、といった個人向け自作ツールとして都合のよい条件が揃っていました。なので、メインドライバが LLM で、私は要望を出してレビューする、というペアプログラミングは素直に楽しく、欲しかった機能が形になって日々の作業が捗るようになった瞬間は最高に嬉しかったです。

各種メンテナンスの作業は全部自分が行う必要がありますが、それもコーディングエージェントに任せると比較的簡単にできるはずです。実際、Zig 0.16 への追従も「could you update for zig 0.16?」という雑な指示から移行を行うことができました。

あなたの手元に starship.toml や .tmux.conf などの設定ファイルがあれば、それはそのまま仕様書になります。「これを実現する小さなツールを作れるか調査してください」と手元のコーディングエージェントに聞いてみると、いいかんじのツールを作ってくれるかもしれません (私の最初のプロンプトも、実際それだけでした)。