AIコーディングした感想

AIコーディング初心者です。

ちょっと前にGoogleのgemini cliが使えるようになったので、その時に初めてAIでコーディングしてみたのですが、動かないコードが出てくることが多くて、まだ無理かな、なんて思っていました。

その後、Kiroがリリースされました。プレビュー版ということで制限がゆるく、Claudeをある程度試すには十分でした。

リリースされた当日に登録したのが良かったのか、待ちもなくすぐに使えたのでラッキーでした。

無料である程度使えるAIを複数使って、どうすればAIがちゃんと動くコードを書いてくれるのか、ある程度答えが出たので、それをメモっておきます。

試したAIは以下です。全部無課金です。

• Gemini
• Kiro（Claude）
• Jules（Gemini）
• Claude
• Chatgpt
• Grok

とりあえず結論

コーディングに関してだけの評価ですが、とりあえず動くコードが出てくるのはClaude（Kiroも含む）ぐらいで、その他のAIはまだ精度が低かったです。ただし、Kiroに関してはClaudeを単体で使う時よりも精度が低いと感じました。

次点がGemini・Grokで、Gemini（Julesも含む）は「ここを治すだけで動くので、本当にもうちょっとでclaudeぐらいにはなるんだけど…」というコードが多く、Grokは書き方はいまいちでも動く、というものが出てきました。Grokは大分意外でしたね。コーディング主体のものが出るみたいなことを何かで見ましたが、出てくるのが少し楽しみです。

Chatgptは、提案ベースではいいけど、フルで書いたコードが全然動かないのが印象的でした。

評価としては、書いたコードを採用できるのはClaudeだけ（それでも書き直しが必要なことも多い）で、他は自分が設計するときの参考にするぐらいでしか使えない感じでした。

雑な指示でもとりあえず動くコードが出てくることが多いのがClaudeでした。ただし、複雑なことをするとClaudeのコードもすぐに破綻します。

Claude以外は、コードレビューに使う、自分で設計する前の参考に使う、設計を細かく指定してひな形（動かなくても良い）だけ作ってもらう、ぐらいが限界かなという評価です。

どのAIも、提案ベースではなんか行けそうな気がする、ことを言ってきて、方向性は間違ってないのですが、実際にコードを書くと動かないということが多かったです。

GeminiはProもFlashも惜しいコードが多かったので、次のモデルあたりで化けるかもしれないですね。

Claudeが一番実用的だなと感じています。課金して使ってもいいかなと思うのは、現時点ではclaudeだけでした。

ただし、指示の出し方には注意が必要なのと、使う側の人間の言語に対するスキルが必要になります。

自分がわかっている設計のコードを、細かく具体的な指示に落とし込んで、AIに依頼すると上手くいく

SNSなどでAIについての言及をみると、まるで魔法のようにアプリが作れる、なんて謳っているものをよく見ます。

疑い深い筆者はそういうのを見るとだいたい胡散臭いと思ってしまうのです。

でも、使わないで怪しいとだけ言っていても意味がないわけでして。

というわけで、実際どうなの？ということを身をもって体験するために、全く知らない言語で、設計するのに必要な技術を調べたこともないものを、試しにAIで作ってみました。

プログラミングを何も知らない人が、ノーコードで魔法のように作れるとは、そういうことだと思うのです。

結果としては、作れませんでした。

今のAIにはまだ魔法は使えません。数年後はわかりませんが。

Kiroで作るRustエディタ（大失敗）

最初にKiroで試したのは、1行もコードを書いたことがないRustで、複雑なテキストエディタを作ることでした。

結果として、筆者が求めた高機能なエディタは作れませんでした。

例えば、Tauriとか、Dioxusとかで、Webベースのtextareaで作るエディタとかだったら、Claudeは簡単に作ってくれますし、とりあえずビルドできるものが出てきます。ただ、その程度のエディタを作るくらいならば、VSCodeがものすごく素晴らしいエディタなわけで、個人用とはいえ、作る必要は全くないわけです。

わざわざ作るに値するのは、動作が速く軽量で高機能で自分専用にカスタマイズ可能な夢のような個人用テキストエディタです。そんなエディタをAIが魔法のように作ってくれたらそんなに素晴らしいことはないだろうと思ったわけです。

無理でした。

specで要件定義をして、設計をして、タスクを作って、タスクを1つ1つ動かしていく形で作りました。

GUIを1から作って細かく日本語IMEを制御して…みたいなことを、細かくタスク分けして進めていったのですが、5個ぐらいタスクを進めると、すぐに破綻しはじめました。

なんどもやりなおしてみました。設計段階でGeminiやKiro自身のレビューを入れたり、途中でエラーの原因を探ったり、テストコードの結果を見てもらって修正したり、などをしましたが、複雑なものほど途中で破綻してどうにもならなくなりました。

大変でした。とても不毛でした。指示を無視されたり、嘘をつかれたり、幻覚を見ていたり、Markdownにルールを書いておくと良いとKiroに提案されてその通りにした指示も無視されたり…。

ただ、この時のAIとのチャットのやり取りは、その後のAIコーディングに大変役に立っています。

現状のAIでは、AIだけでコーディングをして、人間は一切コードを書いたり修正したりせずに、複雑な構造を持った高機能なアプリを作ることは非常に難しいです。

自分がわからないものは、高度で複雑になればなるほど、ちゃんとした品質でAIに作らせるのは無理だということが理解できただけでも良かったです。

キラキラSNSコメントの裏で、とても優秀そうなエンジニアからにじみ出ていた怨嗟の声はこういうことだったのかと、その一端に触れたような気がしました。

Next.jsで作るWebアプリ、Astroで作るWebサイト

少し話が変わりますが、筆者はNext.js、Astroを良く使います。HTML、CSS、JavaScriptなら、なんだかんだ新しい技術だったとしても、MDNなどを見ながら実装できます。

Rustで失敗した後、ふと思いました。自分がわからないものを作るのは無理でも、自分がわかるものだったら、指示の仕方によっては十分使えるのではないか、と。

Webのフロントの部分ならば、とりあえずAIが出してきたコードに対して、筆者でも評価ができます。「こんな構造のWebサイト」「こんな動作をするWebアプリ」は、知識が足りなくても、実装方法を自分で調べてなんとかすることができます。それぐらいの知識があれば、AIが出してきたコードを途中で修正もできるし、細かく指示出しもできるだろうという見通しを立てました。

ということで、次に試したのがAstroでブログ機能を持った最低限のWebサイトのひな形を作ることと、Next.jsで駒を自由に動かせる将棋盤を作ることでした。

AstroのWebサイト

できるだけ単純なものをまず作ってみました。

Astro、TypeScriptで簡単なWebサイトのひな形です。

非常にシンプルで、Astro公式のブログのスターターキットに毛が生えたぐらいのもので、デザインはできるだけ無しで、機能としてもブログとダークモードぐらい、というものにしました。

こちらはKiroではなく、Julesを使って作りました。Kiroを使ってイライラしている時に、正式版がリリースされたので、なんとなく違うの使ってみるかぐらいの軽い気持ちでした。

大分細かく指示しました。「ヘッダーにはサイト名を表示する」とか、そういうレベルまで指示を出しました。

ひな形としては十分なものが出てきました。いくつか不具合があり、こちらでなおしましたが、余計なデザインやいらない機能などがない、スターターのひな形としては十分なものが出てきました。

指示していないアニメーションとかをつけられたりしましたが、CSSの該当部分を削除するだけなので、これぐらいなら許容範囲です。Markdown・MDXで記事を追加できるし、ブログの一覧ページも普通に作成してくれています。

ここから自分で機能を足していったり、根幹部分を書き換えたり、もしくはGeminiとかClaudeとかに細かい単位で機能を追加してもらったり、などをする一歩目としては良いものだと思います。

傾向として、HTMLやJavaScriptの記述よりも、CSSの記述のほうが苦手なのかなという印象でした。これはClaudeも同じですね。

あと仕様にない、まったく言及していない余計なものをつけてこようとするのはどのAIも共通ですね。

完璧なものは出てきませんが、これぐらい単純なものならば、Geminiでもいけるんだなという評価です。

Next.jsの将棋盤

AstroのWebサイトは大分単純なものにしたので、今度は少し複雑なものとして、将棋盤を選びました。

こちらは大変でした。

なんとなくでよければ、一発で作ってくれる時もあります。ただし、その場合はパフォーマンスだったり、ビルドはされるけど機能的にはバグだらけ、みたいな感じで出てきます。

要件を全て見たすものを作るのはだいぶ大変でした。

作った将棋盤は、9×9で、40個の駒があり、成があり、複雑な処理が必要でした。

Reactのチュートリアルが●×ゲームですが、それを大分拡張したようなイメージですね。

最初に自由に動ける盤面を作ったので、そちらではドラッグアンドドロップ機能など、対局には必要ない機能もいろいろ追加しました。

その後、対局ができる機能も付けました。こちらは詰みの判定や、駒移動のルール、持ち駒の打てない場所のルール、先手後手の交互に指すルール、など、自由盤面に追加して様々なルールを追加するなど、こちらも大分複雑になりました。

自由に動かせる盤面はKiroのspecとvibeと自分の修正、対局モードはClaudeのWebのチャットと、全く同じ指示を各AIのチャットに出して、出力を比べたりして作りました。あと大分自分で書きました。

盤面と駒の作成は、将棋のルールの関係上、stateの管理が結構めんどくさいことになるな～と最初から思っていて、だからこそ将棋盤を選んだのですが、Kiroのspecで作っていくと、やっぱりちょっと変な感じになりました。まず設計段階でカスタムフックを作る形にしてなかったり、せっかく作った要件定義を無視したりしてました。

さらに、specが作るタスク分けですが、適切な粒度に切り分けないと、設計書には書いていないレベルの細かい部分で変なことをし始めます。シンプルな実装でOKなのに、やたら迂遠で複雑な実装を始めるのです。

都度、vibeで設計を細かく指示して、動くようになりました。

結局これなら自分で書けばいいんじゃないかなと思いましたが、適切な指示を与えれば、かなりの精度で使えるものが出てきます。

「適切な指示」を出すのが難しいのですが、だいたい以下のような感じだと上手くいく可能性が高かったです。

• 人間が理解していることを指示する
• 詳細を具体的に書く
• タスクを適切な粒度に分解する

詳細を具体的に書かないといけないので、指示を出す側がある程度理解している必要があります。

もう一つ重要なのがタスクの粒度です。とくに、交わることのない全く違う二つの実装を同時に処理させようとすると、精度が落ちることが多かったです。

これを防ぐには、タスクの粒度を決める際の、適切な機能の切り分けが必要で、これは人間側のタスクになります。

また、曖昧な部分があると、こちらが意図していない実装を、AIが独自に推論して実装してしまいます。「将棋のルールはこうなので、一般的にはこの実装が必要！」みたいな感じでタスク内には存在しない機能が入っていて、diffを見て「これなんだろ…？」となったりします。

これを防ぐには、実装に関して具体的かつ詳細を書き、曖昧な部分を排除してしまう必要があります。それっぽい指示でも意図通りに行くこともあるのですが、同じ指示でも同じものが出てくるわけではないので、再現性が高い実装をAIで実現するには、AIが推論する余地を無くさないといけないです。

この見極め部分が難しくて、大分試行錯誤しました。

あと、段階的に実装するやり方もうまくいく確率が高いです。

例えば「駒をクリックして、その駒がルール上で移動可能なマス目にだけ移動できる機能」を作る場合、「歩をクリックしたときにクリックした歩が移動可能なマス目をハイライトする機能」、だけを実装させると、「駒をクリックして、その駒がルール上で移動可能なマス目にだけ移動できる機能」を全て作る指示を出したときよりも、シンプルでわかりやすく理にかなった実装になることが多いです。

機能を分割して、ひな形になるものをまず作り、そこに追加する形をとると、かなり精度が上がります。それでも、元の実装が複雑なものだと、完璧なものが出てくる確率は下がっていきます。

いかに適切にタスクを分解できるかがまず重要です。

その上で、タスクの詳細をできるだけ具体的に書くと、上手くいく確率が上がります。

とりあえずこれぐらいまで指示出せばOKなのね、というのがわかったのは収穫でした。

まとめ

なんとなくの指示で作らせるのは当たるも八卦当たらぬも八卦みたいなものです。

まさにAIガチャです。排出率は決められていません。

できるだけ良いものを当てるためには、詳細で具体的な指示を適切な単位に分解して作成する必要があります。

データの構造とか、渡すpropsとか、決まっているものは細かく指示を出すのが良いです。逆にそれをしないと、直線三歩で行ける場所に斜めに進んだ後にぐるっと回って目的地に着く、みたいな実装が出てきます。

AIの能力を測る目的もあったため、非常に雑な指示をしてみたりとか、AIが設計提案した実装をそのまま書かせてみたりとかしましたが、現段階では「いい感じに作っといて」の指示は、動いても怪しい場所が多かったり、指示した機能が不完全だったり、useEffectが無限ループしたり、いい感じにならないことのほうが多かったです。

SNSに書いてあるキラキラした、なんかAIでもにゃもにゃしてむにゃむにゃするとほにゃほにゃになる的なのは、承認欲求にまみれたアレやろな…、と思っていたので頭から信じていたわけではないですが、でも、もしかしたらって思うじゃないですか。

そんな上手い話はないわけで。

ただ、AIがとても便利なツールになってきて、上手いこと使えば実用的なツールになったというのは、Gemini Flash2.5ぐらいから感じています。

特に文章ベースのものは、雑な依頼で、複雑なそこそこのテキスト量の文章を、それっぽい感じでちゃんとまとめてくれます。もちろんそのままでは使えないですが。

特に得意なのは「指摘」ですかね。Geminiで、GitHubにプルリクするとレビューしてくれる設定をしてみましたが、だいぶ良い指摘をしてくれます。たまに意味不明なものや、間違っているものもありますが、一人で作っている場合にツールで別の視点からの指摘をAIで実現できるのは良いですね。

ZennにもAIレビュー機能が追加されてて、このポエムに対しても評価してくれて、誤字脱字とかも指摘してくれてました。

文章は多分今の状態で十分使える感じですが、vibeコーディングに関してはまだまだだと思います。

ただ、使い方次第では現段階でもコーディング全然いける、というのはわかりました。

そのまま使えるコードを書いてもらうには、できるだけ小さくした粒度で、できるだけ細かく指示する必要があり、結局自分がわかってないとあんまり意味ないな、というのが正直な感想です。

ただ、細かい指示をしたとしても、もともとのアプリが複雑になればなるほど、ハルシネーションの頻度は高まってしまいますし、おかしな挙動をすることも増えていきます。

テストで失敗しているのをみて「いいじゃんこれで実際のコードの問題点を調べられるじゃん」と思って次の動作を確認していたら、AIは「テストの書き方が悪いですね」と判断して、テストコードを修正して無理やりテストをパスしていたのにはちょっと笑いました。（完璧です！（完ぺきとは言ってない））

現時点では、わからないことをわからないと言ってくれない、現状の設計ではできないことをできないと言ってくれない、なんてことが多いので、その辺りもなんとかならんかなと思います。大規模言語モデルの特性と言われればそれまでですが。

でも、数年したらがらっと変わるかもしれない、コーディングでも魔法の片鱗ぐらいは見られるかもしれない、とも思いました。

ここまでAI開発が進んでしまうと、いつになるかはわかりませんが、間違いなくどこかで、テクノロジーの開発とは無縁な大多数の一般人の生活にも、AIが深く入り込むことになるでしょう。

スタンダードな道具になるのならば、ちゃんと使えるほうがいいよね、ということでAIを使ってみたのですが、そのアプローチは間違ってなかったなと思います。

ただ、1つ気になってます。そんなにGPUを大量に使って、大量に電力使って、あれだけ各社が開発競争してて、大丈夫なんですかね。どこかではじけてしまいそうな危うさも感じます。

きっと誰かが、消費電力がめちゃくちゃ低くなった開発環境を作ってくれて、安価で環境にも優しいAI開発がされるんだろうな（されるとは言ってない）的なことにきっとなるんだろうと期待してみたり、まあ無理やろこのまま倒れるまで突っ走るんやろな、最後に立っているのは誰やろな、と野次馬根性出してみたり。権利関係、複雑だなと思ってみたり。

新しい技術が世の中に広がるときは、だいたいそんなものなのかもしれませんね。