予約システム「日和」リリースで見えた、AI駆動開発の勘所と『不認知負債』という課題

はじめに

先日、個人経営の美容院向けの予約システム 「日和」 をリリースしました。 2025年1月から開発を始め、およそ1年をかけて世に出したプロダクトです。

この1年は、生成AIを前提とした開発手法を本気で試行錯誤した期間でもありました。 AIに任せてうまくいかなかった場面、任せ方を変えて一気に進んだ場面、その両方を経験しています。

本記事では、日和の開発で得られた知見を、経営層や意思決定に関わる方に向けて整理します。 「AIで開発は本当に速くなるのか」「どこまで任せて良いのか」という問いに対する、現場からのひとつの答えです。

AIに任せすぎた初期フェーズ

2025年からは、当初からAIを活用した開発を前提にチームを動かしていました。 ClaudeCode や Devin に対して要件を伝え、「とりあえずコーディングしてもらう」スタイルです。

しかし結果として、想定した仕様通りに動かないコードが量産される状況になりました。 表面的には動いて見えるものの、実際のユースケースに流すと挙動が噛み合わない。 デバッグのたびに、AIが生成したコードを人間が読み解く時間が積み上がっていきました。

原因はシンプルで、AIに任せすぎていたことに尽きます。 判断の基準をAIに預けたまま実装が進んだ結果、プロダクトの意図とコードの実態がずれていったのです。

『不認知負債』という新しい負債

この経験を通して、私たちは新しい種類の負債に名前を付けました。 それが 「不認知負債（ふにんちふさい）」 です。

AIが生成したコードをそのまま受け入れていくと、そのコードを十分に把握していない状態が生まれます。 コンパイルは通り、テストもそれらしく通り、見た目には動いている。 しかし 「なぜそう書かれているのか」「どこを触ると何が壊れるのか」を誰も説明できない。 これが不認知負債です。

技術的負債が「意図的に妥協したコード」だとすれば、不認知負債は 「そもそも意図が存在しないコード」 と言えます。 そして厄介なことに、AIを使えば使うほど、何もしなければこの負債は指数関数的に積み上がります。

判断基準を人間の側に取り戻す

そこで私たちは、実装時の 判断の基準 を明文化し、リポジトリの中に置くことにしました。

具体的には次の2つをリポジトリに同居させています。

• ADR（Architecture Decision Record）：なぜその技術・構成を選んだかの記録
• デザインドック：機能ごとの設計意図、制約、採用しなかった選択肢

これらはAIに対するガードレールであると同時に、人間側の判断を残すためのドキュメントでもあります。 AIが書いたコードに違和感を覚えたとき、ADR とデザインドックに立ち返れば「本来こう動くはず」という基準が明確になります。

加えて、AIが意図通りに動かない部分については、その都度人間が実装し直すという運用に切り替えました。 「動かないから直す」ではなく、「どう実装すべきかを人が考えてから、AIに真似してもらう」という順序です。 この順序を守るだけで、生成されるコードの質が大きく変わりました。

ClaudeCode と Devin の使い分け

弊社では現在、ClaudeCode と Devin を併用して開発を進めています。

両者には得意不得意があり、同じ「AIエージェント」とひとくくりにすると使いこなせません。 タスクの粒度、レビューのしやすさ、既存コードの把握精度などに応じて、どちらに任せるかを判断する運用ルールを設けています。

重要なのは、「AIに任せること」自体が設計対象になっているという点です。 ツールを導入すれば生産性が上がるのではなく、任せ方を設計して初めて生産性が上がるというのが、1年間の結論です。

自分の実装を『真似させる』という工夫

不認知負債を減らすために特に効果的だったのが、自分の実装をAIに真似させるというアプローチです。

• 重要な部分は先に人間がリファレンス実装を書く
• AIには「このスタイル・この粒度で残りを書いてほしい」と指示する
• レビュー時は、リファレンスからの逸脱を重点的にチェックする

これにより、AIが生成するコードが人間の理解可能な範囲に収まり、結果として不認知負債が減少しました。 「AIに全部書かせる」から「AIに自分のやり方を拡張してもらう」へのシフトです。

経営層の方へ：1年かけて得た知見

ここからは、投資判断や開発体制の意思決定に関わる方に向けたメッセージです。

AI駆動開発は『任せ方の設計』がすべて

AIを導入すれば自動的に開発が速くなるわけではありません。 むしろ、任せ方を誤れば 不認知負債 という形で静かにリスクが積み上がります。 「AIで何人月削減できるか」よりも、「AIに任せて良い範囲と、人間が握るべき範囲をどう切り分けるか」 が、経営判断として問われる時代になっています。

任せる領域と握る領域の見極めができるようになった

日和のリリースを通じて、私たちは次のことが分かるようになりました。

• AIに任せて生産性が上がる領域：定型的な実装、テストコード、リファクタリングの機械的な部分
• 人間が握るべき領域：ドメインの意思決定、アーキテクチャ、判断基準そのものの言語化

この切り分けは、プロジェクトの規模や成熟度によっても変わります。 そこを毎回チューニングできるかどうかが、AI時代の開発チームの実力だと考えています。

失敗しても戻せる体制になった

もう一つ重要なのは、AIに任せすぎて立ち行かなくなった時に、人間の手で修正できる状態を維持していることです。 ADR・デザインドックを起点に、いつでもコードを設計意図にアラインし直せる。 これはプロダクトの継続性にとって、経営視点でも大きな安全弁になります。

おわりに

日和の1年は、AI駆動開発の理想と現実の両方を教えてくれました。 「とりあえずAIに書かせる」から、「判断基準をドキュメントに残し、人間が設計し、AIに拡張してもらう」へ。 この転換を経たことで、私たちは不認知負債と向き合いながらプロダクトを育てていく体制を手に入れました。

AIを導入するかどうかではなく、どう任せて、どう人間が握るか。 そこに知見と経験を持つチームが、これからのプロダクト開発の差を作っていくと信じています。

日和で得たこの知見は、他プロジェクトや他社の開発支援にも活かしていきます。 「AIを入れたが思ったほど進まない」「生成されたコードが怖い」―― もしそんな課題に心当たりがあれば、ぜひ一度お話しさせてください。