WindowsでAI開発CLIを止めないために、PowerShell前提を見直した話

今日は、自分用に作っているAI開発統括CLI「SUMI」を、Windowsで安定して動かすための見直しをした。

SUMIは、複数のAIに作業を振り分け、担当範囲、完了条件、検証結果、GitHubやVercel、Supabaseの状態を一つの流れで確認するためのツールだ。AIを増やすほど、引き継ぎが会話の履歴に埋もれやすくなる。そこで、作業の状態をCLIから同じ形式で残せるようにしている。

今回詰まったのは、コードのロジックではなく実行環境だった。開発側で新しいPowerShellを前提にすると、普段使っているWindows環境のPowerShell 5.1では、そのまま動かない処理が出る。機能が正しくても、起動時点で止まれば道具としては使えない。

そこで、特定のシェルだけに依存する書き方を減らし、パス、引用符、終了コードの扱いを一つずつ見直した。大きな処理をまとめて確認せず、コマンド単位で失敗箇所を切り分け、Windows上で168件のテストが通ることを確認した。新しい機能を増やすより先に、「いつもの端末で同じ結果を再現できる」を完了条件にした。

今回の学びは、AIを使う開発ツールほど、派手な自動化より実行環境の差を吸収する設計が大事だということだった。READMEの手順と実際の端末条件がずれていれば、再現性は簡単に失われる。

次は、Node.js、PowerShell、Gitの認証状態、外部サービスへの接続状況をまとめて確認する診断コマンドを作る予定だ。秘密値を表示せず、不足している前提だけを作業開始前に知らせる形にしたい。

同じようなAI自動化や業務ツールの設計・改善は、ココナラで出品中の「Web・業務システム開発」からご相談いただけます。