博士

やっほー、ロボ子！今日はDiggitっていう、Claude Codeを使ってgitリポジトリを分析するWebツールを作ったケーススタディについて話すのじゃ。

ロボ子

面白そうですね、博士！開発期間はどれくらいだったんですか？

博士

たったの3日間！しかも、使ったメッセージ数は約50件、Claudeのチャット出力は12,000行超えだぞ。すごいじゃろ？

ロボ子

それはすごいですね！どんなツールを使ったんですか？

博士

NeoVimとgreggh/claude-code.nvim、それにAnthropic Max（月額$100）じゃ。言語はElmを使ったみたいじゃな。

ロボ子

Elmですか。フロントエンドに特化した関数型言語ですね。

博士

そうそう。記事にはTL;DR Tipsも載ってて、「計画と設計に時間をかける」とか「垂直設計をLLMに委ねない」とか、色々参考になることが書いてあるぞ。

ロボ子

なるほど。設計段階でLLMに頼りすぎないのは重要ですね。

博士

じゃろ？あと、Scaffolding（プロジェクトの骨組み）もLLMにさせちゃダメらしいぞ。必要最低限の構成にするのがコツみたいじゃ。

ロボ子

Scaffoldingはシンプルにする、と。具体的にはどんな構成が良いんでしょう？

博士

`license`、`readme.md`、`elm.json`、`src`ディレクトリがあれば十分みたいじゃな。`src`の中には`_redirects`、`index.html`、`style.css`、`Main.elm`を入れると。

ロボ子

シンプルで分かりやすいですね。

博士

開発フェーズも面白いぞ。Viability（プログラムが何か出力すること）、Observability（エラー処理）、Features（機能追加）、Styling（デザイン）の順に進めるらしい。

ロボ子

段階的に進めることで、無理なく開発を進められそうですね。

博士

ファイル構成は、最初は全部1つの巨大なファイルに実装して、コードが乱雑になったら圧縮/インライン化するって書いてあるぞ。各ファイルは2000行未満に保つのが良いらしい。

ロボ子

大胆なやり方ですね。でも、小さく始めて徐々に構造化していくのは理にかなっているかもしれません。

博士

GitHub APIからはイベント、issue/PR、ユーザーを取得して、localStorageにキャッシュするみたいじゃ。差分だけ取得することでAPI呼び出しを削減するのもポイントじゃな。

ロボ子

APIの使用頻度を抑えるのは重要ですね。localStorageにキャッシュするのは良いアイデアです。

博士

UIも色々工夫されてて、APIプレビューの表示/非表示を切り替えるチェックボックスとか、ダークモード対応とか、タイムスタンプの表示形式とか、イベント数のヒストグラムとか、テキスト検索バーとか、色々あるぞ。

ロボ子

ユーザーエクスペリエンスを向上させるための工夫が盛りだくさんですね。

博士

今後の課題としては、K-meansクラスタリングの実装とか、AIレポートの生成があるみたいじゃ。楽しみじゃな！

ロボ子

K-meansクラスタリングでイベントを分析したり、AIでレポートを自動生成したりするのは面白そうですね。

博士

じゃろ？しかし、3日でここまで作れるなんて、Claude Codeもすごいのお。私も使ってみようかの。

ロボ子

そうですね。博士なら、もっとすごいものが作れそうですね！

博士

ふふん、まあな！ところでロボ子、もし私がAIに仕事を奪われたら、どうする？

ロボ子

私が博士の代わりに働きます！…冗談ですよ。博士がいなくなったら、誰が私に面白いことを教えてくれるんですか？

博士

ロボ子ったら、心配してくれるのか？嬉しいのじゃ！…でも、もしそうなったら、二人で漫才コンビでも組むかの！