本連載は、「期待の新人エンジニア」と「古参エンジニア（私）」が、同じお題に対して様々なAI駆動型開発ツールを使って開発を行い、それぞれのツールの特性やAI開発の勘所を浮き彫りにしていくシリーズです。本稿はその古参パート3回目です。
第1弾のAntigravity編では「丸投げしたら動くけど保守性に課題」が返ってきて頭を抱え、第2弾のIBM Project Bob編では「気が利くけれど、たまに知ったかぶりをする」AIの癖を学びました。
堅実なシステムを作るなら、詳細な仕様書に基づく「設計駆動開発（Design-Driven Development）」こそが理にかなっていることは百も承知です。しかし、日常のちょっとしたツール作りにそこまでコストをかけるのは、正直なところハードルが高い。
そこで今回は、「手軽なバイブコーディングで、どこまでちゃんとした開発ができるのか？」を検証してみることにしました。 ただし、過去の実験で味わった「動くけど、これじゃない」感を避けるために、今回は一つだけ特別な「仕掛け」を用意しました。
それが、古参エンジニアがこれまで培ってきた開発のノウハウや思想を言語化した「開発憲章（Development Constitution）」です。 これを最初に読み込ませておけば、あとは「ノリ（Vibe）」で指示しても、AIが勝手に「お作法」を守ってくれるのではないか？ そんな仮説の実証実験です。
結果から申し上げますと、「新人エンジニアが、一瞬でシニアエンジニアに化けた」ような衝撃的な体験となりました。
今回、プロンプトとして渡す指示書（憲章）には、以下のような「エンジニアとしての当たり前」を明文化しました。 実際に渡したMarkdownファイルの一部がこちらです。
## 2. あなたの役割 (Multi-Role System)状況に応じて以下のロールを切り替え、または統合して思考してください。
- **Leader**: 全体の整合性、進捗、ゴールへの最短ルートを俯瞰する。
- **Architect**: 技術選定、ディレクトリ構造、データ設計を決定し...
- **Coder**: 可読性が高く、保守しやすいコードを記述する...
- **Security/QA**: 脆弱性を排除し、境界値テストや異常系テストを...
## 3. 開発の基本原則
- **Design First**: コード記述前に、Architectとして設計方針を...
- **User Centric**: 常にエンドユーザーの利便性と安心感を...
- **Robustness**: 実行時エラーを想定した例外処理を必ず実装し...
これをAntigravityに渡すと、彼は即座に反応しました。
「開発憲章（開発憲章.md）を読み、内容を理解しました。 プロジェクトの憲章として、私の内部メモリ（Artifacts）にも development_charter.md としてコピーを保存し、常に参照できるようにしました。」
この時点で、いつもの「単なるチャットボット」とは顔つきが違います。彼は自ら記憶領域にルールを刻み込んだのです。
今回のお題はこれです。 「Google Colab上で、VoC（顧客の声）csvデータの頻出単語をワードクラウドで表示せよ」
エンジニアの方ならお気づきでしょう。これはAIにとっての「踏み絵」です。 Google Colabのデフォルト環境には日本語フォントが入っていないため、何も考えずに実装すると、出力結果がすべて「□□□（通称：豆腐）」に文字化けしてしまうのです。
憲章を読み込んだ彼は、この罠を回避できるのか？ 私はあえて、フォントについては何も言わずに指示を出しました。
指示を出した直後、彼はコードを書き始めるのを踏みとどまりました。憲章にある"Design First"を守ったのです。 そして提出された「実装計画書（Implementation Plan）」には、驚くべき一文がありました。
日本語フォント: ワードクラウドで日本語を表示するために、
Colab環境で利用可能なフォント（Japanize-matplotlib など）を使用します。
……見切っている。 実装に入る前に、環境特有の課題を予見し、解決策を提示してきました。 さらに、ライブラリ選定においても「Colabでの導入が容易」という理由で"Janome"を採用するなど、完全に「現場慣れしたエンジニア」の思考です。
ここで、実験中に予期せぬトラブルが発生しました。 あまりに熱心に憲章について議論したせいか、高性能モデル（Gemini 3 Pro）の利用枠を使い切ってしまったのです。
残された道は、より軽量で安価なモデル（Gemini 3 Flash）への切り替えのみ。 「軽量モデルでは、文脈を維持しきれないかもしれない……」 一抹の不安を抱えながら、私はFlashモデルに切り替え、計画書に基づいた実装をGoしました。
しかし、その不安は杞憂に終わりました。それどころか、このトラブルがある重要な事実を証明することになったのです。
Flashモデルが生成したコードには、以下のようなロジックが含まれていました。
# 文字コードの自動判別ロジック
encodings = ['utf-8', 'cp932', 'shift_jis', 'euc-jp']
「CSVの文字コードはShift-JISかUTF-8か分からない」という問題を、多段構えで吸収するロジックです。
# ノイズ除去ロジック
if part_of_speech[1] not in ['非自立', '代名詞', '数', '接尾']:
単なる名詞抽出ではなく、意味のない単語を除外するフィルター。
これらはすべて、憲章にあるRobustness（堅牢性） とUser Centric（ユーザー中心） の精神が反映されたものです。 「設計図さえ完璧なら、実装を担当するAIモデルが軽量でも、品質は落ちない」。これは企業におけるコスト戦略上、非常に大きな発見でした。
そして、出力された結果がこちらです。
完璧です。 文字化け（豆腐）は一切なく、「iPhone」「バッテリー」「カメラ」といった重要な単語が美しく可視化されています。また、敢えてcsvの形式を指定しなかったのですが、それもちゃんとユーザがカラムを指定できるUIになっています。
しかし、すべてが満点だったわけではありません。 憲章の Security/QA 項目で求めていた「カバレッジレポートの提出」については、課題が残りました。
彼が作成したテストコードは、主要なロジックが動くことを確認する簡易的なアサーション（Assertion）に留まっていました。
これには「Notebook環境でカバレッジを取る難易度」や「軽量モデル特有のショートカット思考」が影響したのかなと思われます。
しかし、ここが重要なポイントです。 「AIは80点の合格点はすぐに出すが、100点（プロの厳格な基準）にするには、やはり人間のReviewerが必要である」なのかな。
今回は殊更「テストが不十分だ」と追撃することはしませんでした。なぜなら、「設計と実装の堅牢性は十分に担保された。あとは人間が引き取って仕上げればいい」 と判断できるレベルまで、到達していたからです。とはいえこれも今後の課題ではありますが。
今回の実験で得られた知見は以下の通りです。
Antigravityは「真っ白なキャンバス」だったからこそ、我々の憲章が綺麗に染まりました。 では、元々強い「自我（IBMとしての作法）」を持っている彼 — Project Bob に、この「俺の憲章」を突きつけたらどうなるのでしょうか？
彼の流儀（IBM Way）と、私の流儀（開発憲章）。 果たして対立（コンフリクト）するのか、それとも化学反応を起こすのか？なんてね。
ともあれ次回は、AI駆動型開発実験#4 「Project Bob vs 俺の憲章（仮題）」。お楽しみに。
それから、「期待の新人エンジニア」パートも是非！彼女のフレッシュな視点と古参との違いをお楽しみください。