本記事では、エンジニアがつくってきた“自分仕様のAIツール”や“AI活用術”をご紹介します。エージェントやBot、LLM連携ツールなど、実用的なものから、ちょっと遊び心のあるものまで。プロンプト設計やUIの工夫、うまくいかなかったことや思いがけない発見を通して、AIとの付き合い方をのぞいていきます。AIをどう使うかだけでなく、どんな距離感で付き合っているのか。誰かのAIとの向き合い方が、あなたとAIのちょうどいい“さじ加減”の手がかりに。
こんにちは、よしこです。株式会社ナレッジワークでフロントエンドエンジニアやAI活用推進をやっています。 プライベートでもAIエージェントで趣味プロダクトの開発をしています。
みなさんはAIでコーディングを進めるときに、コードレビューはどうしていますか？ 今やコーディングにおいてAIに任される範囲の割合は日に日に増え続けています。 そしてAIに任せる実装範囲が増えるにつれ、アウトプットの量と速度も増し、人間側がレビューを省力化したり手放したりしないと回らなくなってきているのが実情だと思います。
しかし、人間の目を入れずにコーディングを完全にAIに委ねて進めることで、あとから見たときに明らかに非効率な実装があったり、重複する実装があちこちに散乱していた経験が一度はあるのではないでしょうか。 人間にとってもAIにとってもメンテナンスしづらいコードベースが出来上がってしまうと、先々の実装効率もじわじわと下がっていってしまいます。
個人開発などにおいて、毎回PRベースでがっつりレビューするほどでもないけど、ぱっと見てわかるほどの困ったコードが入るのは嫌だから軽く目検ぐらいはしておきたい… そんなライトな差分チェックを組み込んだ自分なりのAIコーディングのワークフローと、それを支えるOSS "difit" を紹介します。
私のAIコーディングワークフロー
簡単に流れを説明すると
- AIエージェントに実装を依頼する
- AIエージェントの実装が完了する
- AIエージェントが実装差分をdifitでブラウザに表示する（人間へのコードレビュー依頼）
- 人間が差分を確認する
- 指摘事項がなければ、ブラウザのタブを閉じることでプロセスが終了
- 指摘事項があればコメントをつける
- コメントがなければ完了。コメントがあればAIエージェントが対応（1に戻る）
このような流れです。3-4で差分ごとのローカルでのコードレビューを挟んでいます。
実際の体験はこんな感じです。
自分で差分を確認しにいくのではなく、エージェントが勝手に立ち上げてくるのが特徴的です。 ここはプロンプト次第なので、勝手に立ち上げないこともできますが、私は勝手に立ち上がることで受動的に差分のチラ見をさせられるところと、実装完了に気付きやすいところが気に入っているのでコミット後に勝手に立ち上がるようにしています。
本腰を入れて自分からコードを見に行くわけでもなく、かといって変更を素通しするわけでもない。ただ勝手に立ち上がった画面をちょっと眺めて、ん？と思ったらコメントするし、想定どおりなら単にCtrl-wでタブを閉じれば立ち上がったプロセスも終了する。 レビューの心理的な負荷を抑えつつ最低限の目検は行える、自分にとってちょうどいいバランスのワークフローだと感じています。
ローカルで差分を表示するOSS "difit"
そんな差分表示を提供しているのはこの自作OSSです。
difit <target> [compare] でtargetの差分を表示できます。HEADコミットの差分を見たければショートハンドとしての difit、コミットしていない差分は difit . 、HEADとmainの差分を見たければ difit HEAD main のように起動します。 なので実はAI関係なく、単なるdiffビューアコマンドとしても重宝しています。
詳しい使い方はREADMEにあります。日本語版はこちら。
主要なユースケース
AIエージェントに立ち上げさせる
npx skills add yoshiko-pg/difit でSKILLをインストールすると、AIエージェントがdifitの使い方をわかるようになります。
私はAIの実装後に自動でdifitを立ち上げてほしいので、個人のプロンプトに「実装完了したらコミットしたあと、difitスキルでユーザーがレビューするための画面を立ち上げて。」と入れてあります。AIにコードレビューを依頼される感覚です。
自動で開くのが嫌な場合は、自分でエージェントに /difit スキルを指定することで立ち上げることもできます。
コメントをつけてAIに指示する
表示されるdiffに対し、指摘事項や質問があればコメントをつけられます。冒頭のGIFのように、コメントを付けてタブを閉じるとプロセスが終了し、つけたコメントが出力されるので、それをコーディングエージェントが受け取って対応をおこなってくれます。
また、 コメントはコピーボタンからプロンプトとしてコピーすることもできます。自動でファイル名と行番号が付与されるので、一通りコメントしたあとにCopy Prompt してチャットに貼り付けることで、そのままAIへの指示プロンプトとして利用できます。
AIにレビューさせる・説明させる
difitで表示できるのはもちろんAIが書いたコードだけでなく、任意のリビジョンやPRの表示も可能です。 その際、AIからコメントをつけてもらうこともできます。この振る舞いは difit-review というスキルとして提供しています。
これを使って、たとえば受け取ったPRの一次レビューをAIにさせたいとき /difit-review https://github.com/yoshiko-pg/difit/pull/123 と伝えれば、AIが内容をレビューしたあとに、レビューコメントを付与した状態でdifitを立ち上げてくれます。ファイル名＋テキストのみでのレビュー結果表示よりもわかりやすいですね。
PRに対してAIによるレビューコメントを付けたいが、そのレビューコメントを事前に人間がレビューしたい、といった「レビューのレビュー」用途にも便利です。
/difit-review は他にも、AIが書いたコードをAI自身に解説させることにも使えます。 実装後に表示された差分が思ったよりも多かったり、変更意図がわかりづらかったりしたとき、「difit-reviewで解説して」のように依頼すると、AIが補足コメントつきでdifitを立ち上げてくれます。
インストール方法
インストールせずに npx difit でも試せますが、インストールする場合は npm install -g difit でグローバルインストールします。 miseを使っている場合は mise use -g npm:difit で入れると、その後の mise up で他のツールと一緒にバージョンアップしてくれるので楽です。 どんどん改善しているのでぜひ最新版を使ってもらえたら嬉しいです。
細かい振る舞いの実現にこだわった、多様なオプション
呼び出し方の好みが人によって違うので、いろいろなオプションを用意しています。
UI自動立ち上げ有無
デフォルトではコマンド実行と同時にブラウザが立ち上がります。それを避けてプロセス起動だけしたい場合は --no-open をつけます。
タブを閉じたときのプロセス終了
デフォルトではブラウザタブを閉じたときにdifitのプロセスも自動で終了するようになっています。実装完了→ブラウザ自動起動→人間チェック→タブ閉じで完了、のようにライトに完結させたかったためです。 ただタブ閉じやリロードで終了しない体験を好む方もいるので、 --keep-alive オプションでプロセスが閉じない挙動にも対応しています。
コメント操作
起動時に --comment オプションにJSONを渡すことで、初期コメントを注入できます。これは difit-review スキルでも利用しています。また、今までに永続化されたコメントを --clean で起動時にリセットすることもできます。
他にもいろいろなオプションがあるので興味のある方はぜひ見てみてください。
difitの成り立ち
ここからは余談というか、思い出話です。
つくったきっかけ
difitをつくる前は、実装後の差分をターミナルのgit diffやエージェントアプリ内のdiff表示で確認していました。 ただそれだとあんまり頭に入ってこない感覚があったんですよね。GitHubのPull RequestのFiles changed画面で確認するのが一番見やすいな、と思ってました。
同様の声をTwitterでも見かけたことで、ローカルでもGitHubのPRの画面を再現できればいいんじゃないか？と思ったのがきっかけです。
指示一発で外出から帰ってきたら完成していた
時は2025年6月。当時最先端だったChatGPT o3と壁打ちしながら要件定義書を出力して、Claude Codeに実装させるというのが自分のいつものフローでした。なのでその時も、以下のプロンプトをChatGPTに打ち込みました。
ここからいくつかの対話を経て作成したrequirements.mdが以下です。（initial commitに残っていました。指示書もコミットしておくと思い出を振り返れていいですね）
そして空ディレクトリにこの指示書を置いて、Claude Codeに「requirements.md 実装して」と言い残して外出しました。まあどっかで止まっちゃうだろう、と思いつつ。
そして帰ってきたら、なんとアプリが完成していました。
まだまだ使い勝手は悪いものの、ちゃんと動いています。
今や珍しくもないことかもしれませんが、指示一発でエラーなくアプリができあがったのは当時の私には初めての体験でした。しかもローカルのgit diffをWebアプリとして表示するにはローカルサーバーを立ててAPIも生やさなきゃいけないし、そこそこ複雑なのですが…
帰ってきて動かしてみて、かなり驚いたのを覚えています。
翌日リリース、その日のうちに100Star
感動冷めやらぬまま、少し手を加えて翌日には v1.0.0 としてリリースしました。
Zenn記事: AIが書いたコードをローカルでレビューできる「ReviewIt」を作った
出した直後からかなりの反響があり、その日のうちにGitHub Starが100を超えました。ローカルで手軽に差分を確認したいニーズは想像以上に大きかったようです。リリースから3週間後には1000Starを突破しました。
私はGitHub Pagesで小さいアプリケーションを公開したことは何度かあったのですが、個人でOSSを公開した経験はほとんどなかったので、興奮と共に焦りもありました。運用ちゃんとしていけるのかなぁ…と。
なので運用上のセキュリティ面は改めて情報収集をして、GitHubのPublic Repositoryなら無料で使えるCode Scanningを有効化したり、npmのtokenをCI上に置かずにpublishできるTrusted Publishingに移行したり、RenovateにminimumReleaseAgeを指定したりと、このあたりのベストプラクティスを再確認する機会になってよかったです。
リリース5日後、予想外の連絡が来た
最初は reviewit という名前で公開していたのですが、リリース5日後に類似名称のサービスを運用されている会社さまからご連絡をいただき、商標の関係で命名を変更することになりました。
Zenn記事: Git diff閲覧ツール「ReviewIt」が「difit」に変わります
予想していなかった展開に当時は動揺もありましたが、散々悩んで決めた difit という新しい名前は打ちやすくてnpmのnamespaceも空いていたし、結果的によかったなと思います。そしてOSSであっても商標検索はしておいたほうがいいのだと学びました（とはいえ reviewit で検索しても引っかからなかったので、難しかったのですが…）
このときに新名称でロゴもつくりました！これも原案はAIですが、フォントの丸みが気に入っています。
リリースパイプラインの整備
運用の工夫として、リリースの手順をミスるのが怖かったのと、Changelogを自分で書くのも大変だったので、リリースフローを早々にClaude Codeのスラッシュコマンドにしました。
Zenn記事: Claude CodeのカスタムスラッシュコマンドでのOSSリリースが便利
publishはもちろん、その手前でコミットログを見てChangelogを自動生成してくれたりします。 これは早めにやっておくことでその後のリリースもスムーズになりましたし、OSSを運用しないとこういう経験もできなかったので良かったなと思います。未だにこの方法でリリースしていて、とても便利です。
最後に
ちょっとした便利ツールとしてつくってみたものが思った以上に多くの方に使っていただけて、素直に嬉しかったです。海外の方からもよくPRをいただいたりすることで広がりを実感します。
ただ、昔も今もdifitは自分のための便利ツールなので、自分にとって一番便利なものをつくる、という考えは忘れずに育て続けたいです。フロントエンドエンジニアとしてUIや体験にもこだわりがあるので、そういった力試しをできる場としても重宝しています。
とはいえ反響はとてもモチベーションになりますし、issueやPRで改善できたこともたくさんあります！コントリビュートしてくださったみなさま、ありがとうございます。 感想ツイートやGitHub Starもとても嬉しいです！
リポジトリは以下です。ぜひ使ってみてください！