開発記事でAIとの協業をちゃんと書くことにした理由

はじめに — 記事を読み返して気づいた違和感

ZERONOVA LAB では37本の Journal 記事を公開しています。技術記事や開発ストーリーを書いてきましたが、最近すべての記事を読み返して、ある違和感に気づきました。

記事の中で、AIとの協業がうまく伝わっていない。

「RLS first で設計した」「1日でMVPを構築した」「6プロダクトを同時運用している」と書いているのに、それを実現している最大の要因 — Claude Code との協業 — が記事の表現に反映されていなかったのです。

ZERONOVA LAB は「AIネイティブ実験スタジオ」を掲げています。サイトのコンセプトとしては最初から打ち出している。でも、肝心の記事でその開発スタイルが読み取れないなら、コンセプトと記事の間にギャップが生まれてしまう。

問題 — 記事だけ読むと「すごいエンジニア」に見える

読者の立場で考えてみます。

1日でMVPを作る — Supabase フル活用の高速開発術を読むと、1人のエンジニアが1日で認証、データベース設計、リアルタイムチャット、検索機能まで実装した、という印象を受けます。

個人開発で6プロダクトを同時に運用する方法を読むと、超人的なエンジニアが効率的に6プロダクトを回している、という印象を受けます。

しかし実態は違います。

私はPM（プロダクトマネージャー）であり、エンジニアではありません。「何を作るか」「なぜ作るか」「どの方針で進めるか」の判断に集中し、実装は Claude Code に依頼しています。コードを直接書くのではなく、要件を伝えて出力をレビューし、修正を依頼するサイクルを回しています。

AIとの協業はコンセプトとして打ち出しているのに、記事の表現がそれに追いついていなかった。結果として「PMがAIと組んで高速にプロダクトを作っている」という実態が伝わらず、ブランドにとっても読者にとっても損をしていました。

なぜ表現できていなかったのか

意図的にAIの関与を省いていたわけではありません。

最初の記事を書いたとき、自然と「〜を実装した」「〜で解決した」と書いていました。技術ブログの慣例として、主語は開発者自身。AIとの協業をどう表現するか、まだ自分の中でスタイルが確立されていなかったのです。

つまり、コンセプトは持っていたのに、記事という形式に落とし込む方法が分かっていなかった。

3つの理由で表現を改善することにした

理由1: コンセプトと記事の一貫性

ZERONOVA LAB は「AIネイティブ実験スタジオ」です。AIを活用して高速にプロダクトを生み出すことがアイデンティティ。コンセプトではそう打ち出しているのに、記事でその開発スタイルが読み取れなかったら、コンテンツとしてもったいない。

コンセプトに合わせて、記事の表現もアップデートすべきだと考えました。

理由2: 読者への価値

2026年現在、「PMやディレクターがAIと協業して開発する」というスタイルは多くの人が関心を持っているテーマです。

• どうやってAIに要件を伝えているのか
• 設計判断はPMとAIのどちらが主導しているのか
• AIの提案をどう評価して採用/却下しているのか

これらは技術的な実装方法よりも、むしろ多くの読者にとって価値がある情報です。記事で表現しないのはもったいない。

理由3: 著者ペルソナの正確さ

私はPMです。記事で「実装した」と書くと、読者は著者をエンジニアだと認識します。しかし私が実際にやっているのは「実装をAIに依頼して、結果をレビューして、方針を判断すること」です。

この違いを記事の中で正確に表現することで、読者に正しく伝わると考えました。

具体的に何を変えたか

表現ルールの策定

まず、記事で使う表現のルールを決めました。

ポイントは「AIが作った」と書くのではなく、PMとして判断・レビューしたことを明示する点です。AIはパートナーであり、判断の主体は人間のままです。

対話セクションの導入

記事の中で、意思決定の分岐点に「PMとAIの対話」を挿入する形式を導入しました。

たとえば、RLS の設計方針を決める場面：

Zeronova

依頼データにクライアントごとのアクセス制御が必要になる。APIルートで毎回チェックするのは漏れが怖い。

Claude Code

RLS をデータベース層で設定しておけば、APIルートでの認可チェックが不要になります。「デフォルト拒否」で設計し、必要な権限だけ付与するのが安全です。

Zeronova

APIルートがシンプルになるし、認可漏れのリスクも減る。RLS first でいこう。

この形式のメリットは：

• PMの判断プロセスが見える: 読者は「なぜその方針を選んだか」を追体験できる
• AIの役割が明確になる: 技術的な提案と根拠を出すのがAIの仕事
• 開発のリアリティが伝わる: 実際の開発プロセスに近い表現

2段階のレベル分け

全記事に対話を入れる必要はありません。AI協業の表現を2段階に分けました。

• レベル1（言及）: 「Claude Code で実装した」のように、文中で自然に AI の関与を記述する
• レベル2（対話）: 意思決定の分岐点で、PMとAIの対話セクションを挿入する

技術記事ではレベル1を基本とし、開発ストーリーではレベル2を積極的に活用します。

既存記事の表現を改善

37本の既存記事を全部書き換えるのは現実的ではありません。創作禁止ガイドラインがあるため、devlog に記録のない対話を後付けで入れるのは事実に反します。

そこで、特にAI協業の表現が重要な3本の記事を選んで改善しました。

• 個人開発で6プロダクトを同時に運用する方法 — AI協業なしでは6プロダクト運用の説明が伝わらない
• 1日でMVPを作る — Supabase フル活用の高速開発術 — 「1日で作れる」の核心がAI活用にある
• 個人開発で「完璧主義」をやめた話 — リリース判断にAI協業が関わっている

残りの記事は時間のあるときに順次改善していく予定です。

コンセプトと記事の一致が信頼になる

この改善で考えたのは、「サイトで掲げているコンセプトと、記事の内容が一致していること」の重要性です。

ZERONOVA LAB のトップページには「AIネイティブ実験スタジオ」と書いてある。でも記事を読むとAIの気配がない。この不一致は、読者に「結局どっちなんだろう」という印象を与えてしまいます。

コンセプトに合わせて記事の表現をアップデートすることで、サイト全体の一貫性が増す。プロダクトの価値は「誰が作ったか」ではなく「何を解決するか」で決まるし、「PMがAIと組んで、これだけのプロダクトを高速に生み出せる」という事実は、AIネイティブ開発の可能性を示すものとしてポジティブに受け取られるはずです。

まとめ — コンセプトを記事でも体現する

AI協業の表現を改善した理由を整理すると：

1. コンセプトと記事の一貫性: 「AIネイティブ」を掲げるなら、記事でもそれが読み取れるようにする
2. 読者への価値: PM×AIの協業プロセスは、多くの開発者・PMが知りたい情報
3. 著者ペルソナの正確さ: PMとしての役割が正しく伝わる表現にする

今後の Journal 記事では、PMとAIの協業を自然に記述し、意思決定の場面では対話セクションを活用していきます。「AIネイティブ実験スタジオ」の開発プロセスをリアルに伝えることで、同じように AI を活用して開発を進めたい方の参考になれば幸いです。