コンテンツにスキップ

最近の趣味プロとVibe Coding

Author: Kazukichi
  • 最近、趣味でやっているプロジェクトをいくつか改修した
  • その中でVibe Codingを試してみたのでそのナレッジ共有
  • AIエージェントはRoo Code(Clineのフォーク)、APIキーはOpenRouter、LLMのモデルはClaude 3.7 Sonnetを主に使用
  • 他にもChatGPT 4o、 GitHub Copilot コードレビュー も使用
    • GitHub Copilot コードレビューは CodeRabbit 的な感じだと思われる
  • 高田ゼミはプライベートリポジトリでマークダウンの発表資料を管理していた
  • リポジトリをパブリックに変更し、Astro + Starlight構成をGitHub ActionsでGitHub Pagesにデプロイ
  • たかしの発表を参考にした: Starlight
  • デプロイ先: This Is Kazukichi
  • 2018年からメンテしているので7年目と結構歴史がある
  • コンテンツはシンプルで静的な上、CSSはほぼ書いていないので移行しやすく、従って色々と実験もしやすい
  • Vue 2 -> create-react-app -> Vite + Reactと変遷してきた
  • たかしの発表を参考にした: React Create App との別れ
  • 今回、採用した構成としては以下
技術カテゴリ改修前改修後備考
Node.js18.15.022.14.0最新のLTSを採用
パッケージマネージャNPMPNPMPNPM = Performance NPM。ディスク容量の節約、速い速度、高い堅牢性
フレームワークReact (CRA)React (Vite)Create React App(CRA)がお亡くなりになったため
AltJSTypeScriptTypeScriptバージョンはあまり意識していない。AltJSとか死語では
バンドラwebpackesbuild + rollupesbuildはGo製で高速なのでホットリロードに最適なので開発時の利用、RollupはTS製で最適化が得意なので本番ビルド時の使用
トランスパイラBabelSWCSWCはRust製で超高速
リンター/フォーマッタ-BiomeBiomeはESLintやPrettierを統合して扱える。どうせほぼレコメンド設定で使うので採用
pre-commit-lint-staged + husky定番設定。Biomeをコミット時に自動実行するために必要
  • GoogleのPageSpeed Insightsで改修前後のパフォーマンスを計測したけど目立った変化は無し
  • Google Fontsを初めてNPMパッケージから使った
    • いつもフォントファイル(WOFF)をダウンロードしたり、CDNから読み込んだりしていた
    • Inter + Noto Sans JPを使っている
  • vite-imagetoolsの活用
    • next/imageみたいなかんじだと思う
    • 画像を圧縮したり、WebPやAVIF形式で簡単に配信できる
  • コード行数がかなり減った
  • コナミコマンド + ゲーミングモードを実装した
    • ↑↑↓↓←→←→BAでおなじみの
    • クソ機能
    • 実演
  • カスタムフック初めて使ったけど便利
  • OGP対応、Dependabotの設定等もきっちり行った
  • 久しぶりのWebフロントエンド、楽しかった
  • SIBYL SYSTEM(包括的生涯福祉支援システム)と呼んでいる(厨二病)

    • PSYCHO-PASSのオマージュ
  • 電気代、給与、活動時間等、を包括的に可視化するためのアプリ

    • プライベートリポジトリ
    • データソースは随時追加中
  • 2023年春(2年位前)からぼちぼち運用

    • 拡張性に乏しい設計で、データソースの新規追加が面倒だったので意を決してリファクタリング開始(まだ途中)
  • 技術スタックはPython + SQLite + Metabaseだが、データソースの解析部分はフルスクラッチに近い

  • 今回、採用した構成としては以下

技術カテゴリ改修前改修後備考
Python3.93.13最新バージョンを採用
パッケージマネージャPipenvPoetry最近だとuvとかRyeも出てきているけど、CI/CD連携等の視点で心配
  • 他にもMetabaseのバージョンアップも行った
  • ひたすらリファクタリング
    • Roo Codeの全力で数十時間かけてもまだ納得のいくコードになっていない
    • リファクタリングでOOP/デザパタの知見がかなり得られた
      • 個人的に小5(プログラミング開始)、専門1年生(先輩にVue/Laravelを教えてもらう)、以来の成長曲線
    • 今まで同じバックエンドエンジニアという職種でそこまで何でも聞ける間柄の人はいなかったのも要因の一つ
    • ChatGPTも良いが、コードベースを広く見てコンテキストに載せられて、かつ、実際に操作もしてくるのでレベルが違う
  • リファクタリングが終わったら、体重とか他のデータソースに対応したり、サーバレスにしてどこかにデプロイしたりしたい

事例4: 超次元オセロ イナズマシックスティーフォー

Section titled “事例4: 超次元オセロ イナズマシックスティーフォー”
  • 一言で言うと、拡張されたオセロ
  • ゼロベースでフルでVibe Codingしながら作った
    • つまり、コードベースをあまり理解していないし、ほぼ自然言語だけで指示した
    • 半日ぐらいかかった
  • 技術構成は主にPygame
  • リポジトリ: https://github.com/tyokinuhata/inzm-64
  • 名前はイナイレのオマージュ
  • 色んなサイズの盤面、色んな強さのAI、色んな拡張マス(爆発、ワープ、ミラー)、色んな対戦形式(人間 vs 人間、AI vs AI、人間 vs AI)を実装した
  • 実演
  • 強化学習ベースのオセロAIを実装したり、エクストリーム機能を増やしてみたりしても面白いかも
  • #100日チャレンジ 毎日連続100本アプリを作ったら人生が変わった に触発されてやったみたいなところある
  • Vibe Codingでも未踏の技術領域のソフトウェアが実際に動作すると面白いし、その分野の技術を概念レベルで習得することはできる
  • Vibe Codingの有効活用や成長にどう活かすか、等は今後もぼちぼち続けながら模索していきたい
    • 仕事もそうだけど、ハッカソンでのムーブも大きく変わってくるんだろうなという印象

どういうふうにコードを書いているのか

Section titled “どういうふうにコードを書いているのか”
  • ChatGPT 4oとやりとりしながら、要件定義、設計、技術選定を行う
  • 設計フェーズではコードもドキュメントもほぼ無いので、コンテキストの扱い方にあまり注意する必要がない
  • チャット単体ならRoo Code等と比べて使いやすいUIを持っており、かつ、従量課金でも無いので使いやすい
  • プロジェクトの初期化やGit操作は主に手作業で行う
    • 言語処理系やパッケージマネージャの準備、Gitリポジトリの準備はほぼ定型作業かつ、最適なものがある程度分かっている
  • 必ずしも(狭義の)Vibe Codingをしているわけではない
    • Vibe CodingとDocDDの中間のような感じ
    • コンテキストを整備したり、プロンプトを工夫したりしながら、ある程度、実装やテストに対する確認はする
    • というのも、コードベースが大きくなると、実装やテストを捻じ曲げ始めるし、積極的にリファクタリングしてくれない
    • ある程度、大局的な(アーキテクチャ的な)理解はしていないと、コードベースが破綻する(拡張できなくなる)
    • そういう意味では、ソフトウェア設計(上流〜実装、テストレベルまで含む)の知識は必要
    • CDD(Context Driven Development)と呼ばれたりもするらしい
    • 最近はインスタント開発という改修の度にゼロから作り直すという開発手法も提唱されているらしい
      • ビルドの度にコンテナを作り直すimmutableの概念みたい
  • AIエージェントはRoo Code、LLMのモデルはClaude 3.7 Sonnet
    • 割と現在の環境で推奨されている構成
  • コンテキストは主に README.md.clinerules に書く
    • OpenAPIとか、MCPサーバを立ててコンテキストを注入するのも良いかも
  • こまめにコミット
    • これは人の手で実装するときと大きく変わらないが、AIエージェントを使うと大きい変更が入りやすい
    • 機能追加/バグ修正 + テスト追加/修正でコミット
    • リファクタリングでコミット
    • 上記2つのフェーズを高速で回す
  • どんどん承認が適当になる
    • とりあえずAuto Approveして動作してから確認するか、となってくる
    • 家事をしながらコードが書ける素晴らしさ
    • ただし、コマンド実行だけは破壊的な変更をする可能性があるので手動で承認している
  • バグの解消
    • 定期的なリファクタリングとテストの実装はAIエージェントにおいてもバグを防ぎやすい
    • それでもバグが発生した際には、バグの発生条件を詳細に記述したり、マルチモーダル性を活かして画像を添付したりする
  • モード
    • Code / Architect / Ask / Debug と様々なモードがある
    • 基本的に質問したいときはAsk、コードを修正したいときはCodeを使っていれば問題なさそうな印象
  • 的確な修正をしてくることが多い
    • ChatGPTに比べてコードベースの情報を深く理解している(コンテキストが多い)ので
  • 実装のペースが高速化される
    • 具体的なソリューションが分からない場合もとりあえずRoo Codeに投げてみる
    • Roo Codeが出してきたコードをコードリーディングして理解する
    • 自分のコーディングとは違うアプローチ、もっと良いアプローチが出てくることもある
  • 心理的な障壁がかなり低くなるので、面倒だけどやらないといけないことに取り組みやすい
    • ADHD御用達
  • .clinerules を遵守してくれない
    • XXしてはならない、XXを禁止するのような否定形のルールは特に守ってくれない
  • 頼んでいないことをやってくる
    • 頼んでもないCSSを勝手に入れたり、インストールだけ頼んだのにバリバリ設定書いたり
    • 暴走機関車
    • Roo CodeとClaude 3.7 Sonnetという組み合わせがそうさせているのかも
  • 不要なコメントをガンガン入れてくる
    • 実装から自明なものが大半
  • 手作業が億劫になる
    • 手作業でコードを変更すると、AIエージェントによる余分なAPIリクエストが発生したり、元の状態にサイレントに戻してくることがある
  • 金がかかる
    • すでに$100以上課金している
    • ファイル数/コード行数が多くかつ、定型的な修正が必要な場合、クレジットがどんどん消費されるし、かといって人力でやるのもな…という気持ちになる
    • Prompts Cachingの発展に期待
  • インデントがバグりがち
    • 地味に面倒
  • マイナーな技術分野の実装が下手くそ
    • AstroやStarlight、dependabotの設定のようなあまり学習されていない新興のフレームワークは頓珍漢な回答/修正が比較的多い
  • デザイン修正が苦手
    • スクショを送ったりはできるものの、基本的にデザインの微調整は苦手そう
  • あくまでもローカルで行えることに完結している
    • 例えば、GitHubにissueを立てたり、PRを作ったり、みたいなところまでは自動でやってくれない
    • そういうところまでやってくれるのがDevinという認識
  • Devin / Windsurf / Claude Code / Codex / Mastra等のツール/ライブラリを使ってみる
  • MCPやA2Aのような基盤技術に触れる
  • プロンプトエンジニアリングを学ぶ
  • AIエージェントでもTDDベースで実装する