※この記事は多分に主観を含んでおり、フロー等も検証中、諸々の結論も出てなかったり仮の状態です。ご注意ください。
生成AIでコード書けんの？え、何それめっちゃ楽では？
画像生成AI「Midjourney」から始まり数多の生成AIが戦国時代の武将が如く現れる昨今。
「へー、AIに情報食わせたら学習して絵も出力できるんか。楽しいオモチャだ」
最初はそんな認識だった。
え、エラー箇所の特定できるの？設計の相談乗ってくれるの？コーディングしてくれるの？
めちゃくちゃ未来のツールでは？？？？
初期の頃はChatGPTを主に使ってミニマムにコーディングを行っていたけど、今はClaude Codeを使用しています。時と場合とトークン量によってGithub Copilotも使うけど。
で、そのClaude Code。MCPとやらと繋げばまあ便利、らしい。ほーん？
へー、Atlassianの読み込みができる。Figmaのデザインも設定ベースで参照できると。ほーん。
な る ほ ど ？
そんなわけで、私がやってみた感想を覚え書きで書いていく。
Claude Codeを使用したコーディングでやってはいけないこと
最初に、この項目は個人的な自戒である事を明記しておく。「試したら上手い事いったじゃん！嘘つき！」といったクレームは受け付けません悪しからず。
Claude Codeの使い方も最初は覚束なく、ChatGPTと同じ使い方をしていました。MCPをそれとなく理解できたあたりから直接リンクを貼ってプロンプト書いて...。今思うと見辛いことこの上ない。
あー、そうか。設計書を読み込んだら実装まで持っていってくれるなあ。設計書の中にFigmaのリンク貼っておけばこれも勝手に読んでくれるじゃん。
設計書ってたまに時間なくて書けない事もあるし、先に書いておけば一石二鳥じゃん。
とまあ期待値MAXでClaude codeにコーディングさせる検証を行った結果、「やらかしたな」と思ったことがいくつもあるわけですよ。
別のブランチを見に行くな
発端は似たような画面、似たような機能の実装をそれぞれ別ブランチで実装しようとした事だ。
どうにも、指示すると別ブランチも見にいってくれるらしい。
それならとブランチAに最初の実装を行い、ブランチBを作業ブランチに設定して「ブランチAの画面/aを参照にブランチBで画面/bを作ってください(実際はもう少し細かい」と指定してみた。
結果。
「ブランチBからチェックアウト、ブランチAに切り替え」
「ブランチAを読み込み」
「ブランチAからチェックアウト、ブランチBに切り替え」
「実装内容〜」....
あ、そんな手間がかかる感じなのね？
トークン大量に消費して、精度もちょっと良くない。やるなら「ブランチAをブランチBに取り込んで画面/aを参照する」が一番良さそう。
同時に実行するな
設計書A(画面複数枚に渡る申込機能A)があります。
設計書B(画面複数枚に渡る申込機能B)があります。
Q.設計書Aと設計書Bを同時に読み込ませて実装させるとどうなると思う？
A.トークンが吹き飛びます。
一瞬でトークン消費量100％(当方プロプラン)。精度もそれほどよくはない(設計書が悪いのもあるけど)。効率化求めて真逆突き進んどるやないかい。
小さなファイル単位の実装ならいいものの、複数の画面を一発で実装させるとどうにもトークンの減りが激しい。実装も完璧ではないのでどうしても手作業(AIへの修正指示含む)は発生する為、一気にトークンを持ってかれると死活問題甚だしい。
結論。横着するな。
設計書てどうすりゃいいんや
最初はAtlassianでぎっちり書こうとしてたけど、途中で面倒になったので「Atlassianに書いたざっくり設計書をmdファイル化させて不足分はClaudeに指示して足していけばいいじゃん」と方法を切り替えてみた。ほら、今検証中だから何度も実行させるわけですよ。いちいちAtlassianの内容変更→MCP経由で実行だと面倒じゃないですか。真・設計書はmdファイルで進める方が絶対早い。ということで今はmdファイルで進めています。
いざ実行。
Claude Code「ここら辺決まってないみたいやし勝手に補完して作っといたで！」
いや、思ったのとだいぶ違うな？
既存のコンポーネントが使われてない。なんなら勝手に類似コンポーネント作ってみたりもする。
設計か。設計が悪いのか。
なのでClaude Codeに指示をして設計に諸々を追加させる。
「画面Aは既存画面Bを参照」
「この部分はコンポーネントCを使用する」
「新規機能Dは既存機能Eを参照」
「画面デザインはFigmaのこのリンク参照」etc...
何度か設計に追加→実行を繰り返していくと、及第点とは言い難くもなんとか妥協点にはたどり着いた気がする。
設計書として必要な要素はまた改めてまとめたい。
Figma MCP
Figmaの課金プランから使える機能。え、Figmaのリンク貼ったらそれを参照して画面デザイン実装してくれんの？最高！デザイン内で使用しているアイコンもSVG画像として勝手にダウンロードしてくれるらしい。ヒャッホウ！
そのデザイン、ほんとに合ってる？
実行してみると、どうにもデザインが崩れる。ディレクトリ構成もかなり単純化させてもダメ。原因はFigmaのデザインそのものにありました。
「どっちも同じでは？」と思ったそこのあなた。大丈夫、私も思いました。
大丈夫なパターンはこのAuto layoutをかけています。じゃあ何でわざわざAuto layoutをかけるのか。
Figmaにおけるデフォルト設定がhtmlと違うからです。
こちらがダメなパターンの設定。これをClaudeCodeに読み込ませて実装させると、赤と青の要素がposition=absoluteになります。確かにFigmaでデザインを触っているとabsoluteだわ。Claudeの読み込みは設定準拠なのでそりゃabsoluteになるわ。
画像ダウンロードさせる必要、ある？
先で書いたSVG画像のダウンロード、本当にさせていいのか？正直ここのところは今でもどうするか決めかねているところはある。何故かって？出力されたものが正解とは限らないから。サイズもデザインも全く違うものが出力された時は頭を抱えました。
今のところは「とりあえずダウンロードさせて、画像は後から差し替える」が一番実装が楽な気はするけど、トークンとのご相談必須だし、トークン使ってまでやる必要あるか？と言われたらうーん。
カスタムコマンド、使えるのでは？
実装に話は戻る。現在のやり方では既存コードガン無視で実装してくれるからこれがしんどい。新しい画面を実装する度に「ヘッダーとmiddlewareと〜を書いて〜」という設計を追加しないといけない。
その他細かい設定がエトセトラ。いや面倒臭いわ。
あ、カスタムコマンド使えるじゃん。こちらは検証不足であまり言えることは少ないけれど、そういった細かい部分の設定はここに突っ込めばいい。
現在考えているコマンドは2種類。
Atlassianの設計を実行用設計mdに起こすコマンド
多分、必要な要素を通常の設計ベースで書いても絶対穴は空く。なのでこのコマンドに必要な要素をパターン等含めて記述しておいて、それを参照させながらmdファイルを作成させる。必要な部分が欠けていたりするなら「ここを追記しろ」みたいに一目見てわかりやすくしていきたい。
実行用設計mdを基に実行するコマンド
コーディング規約、命名規則、ディレクトリ配置etc。それらを全部参照しながら実装を行い、レビューし、修正…といった流れを実行させるコマンド。
ただでさえ普通に実装させるだけでも時間がかかるので、レビュー等も含めると更に時間はかかるしトークンも消費する。まあそこは仕方なし。このコマンドはより精度を上げていきたいところ。
余白
正直なところ、まだまだアップデートの余地はある。カスタムコマンドも、私が一人で最強のコマンドを作成できるとは思ってないので秘伝のタレの如く必須要素を継ぎ足していくしかないとは感じている。できたらいいんですけどね。
完全な結論も出ていないので、今回は一旦ここまで。都度追記はしていく予定です。
どっとはらい。
Discussion