コードを書かない人がプロダクトをつくる。Jicooで半年かけて組み上げた「ハーネス」と「ループ」

現在 Jicoo（ジクー） のエンジニアは、自分でコードを書く時間がほぼゼロになりました。コードを書くのは AI です。そして、コードを書けないカスタマーサポートやカスタマーサクセスのメンバーが、自分で起票したカイゼンや不具合を、自分で直してリリースまで持っていく。そんなことが、毎日起きています。

この半年、私たちは AI に開発を任せるための仕組みを、少しずつ組み上げてきました。AI の 1 回の仕事を安全にする仕組みを「ハーネス」、人が課題を渡さなくても改善が回り続ける仕組みを「ループ」と呼んでいます。この記事では、プロダクトオーナーの立場から、なぜそうしたのか、どこでつまずいたのか、そして何がまだできていないのかを、できるだけ正直に書いてみます。

きっかけは、「コードを書けない人も、開発に参加できるのでは」という思いつき

2025 年の春、Devin のような AI 開発エージェントを試し、そのあと Cursor のようなコーディング補助ツールを使うようになりました。Cursor を触っているうちに、「これならコードを書けない人でもプロダクト開発に参加できるのではないか」と思ったのが出発点です。

顧客の声をいちばん近くで聞いているのは、サポートや営業のメンバーです。その人たちが自分で直せるようになれば、開発は速くなります。採用の問いも、「エンジニアを何人採るか」から「プロダクトに関われる人を何人にするか」に変わります。

ちょうど、それを実現できるだけの性能が AI にも備わってきました。いくつかのタイミングが重なって、2026 年 3 月に、ハーネスの最初の土台を入れました。

エンジニアたちからの大きな抵抗は、ありませんでした。もともと「AI エージェントのほうが優秀だ」と感じていたメンバーもいたほどです。とはいえ、最初から全面的に信頼できたわけではありません。AI がコードを書くたびに、自分でテストして確かめていたメンバーもいました。それが今では、設計から実装、テストまでを AI に任せ、人間は仕様どおりか、テスト結果が問題ないかを確かめるだけで、リリースまで進むようになっています。複数の部品にまたがる大きな移行のようなものは、まだ人が見たほうがいい。そういう線引きも、チームの中で自然にできてきました。

ハーネスとループ

ハーネスは、もともと馬につける馬具のことです。どこまで自分で走っていいか、どこで止まって人間に聞くか。それを決めておく仕組みを、私はハーネスと呼んでいます。

AI にコードを書かせること自体は、もう難しくありません。難しいのは、書かれたものを誰がどう信用するかです。

ハーネスは、AI を縛るためのものではありません。AI が変な方向に行かないためのガードレールであり、安心して走らせるためのものです。チームでは、ハーネスを「プロジェクトメンバーとしての AI の人格」のように捉えています。AI が間違えたら、メンバーに次から改善してもらうのと同じように、ハーネスのほうを直す。そういう感覚です。

もう 1 つ大事にしているのが「ループ」です。自律的かつ継続的に、自動で改善していける仕組みのことです。ハーネスで 1 回の仕事を安全にしたうえで、その仕事が人の手を介さずに回り続けるようにする。後半で詳しく書きます。

「全部 AI」は、コストで引き戻された

最初は、実装もコードレビューも全部 AI に任せる設計でした。コードレビューを AI に任せる仕組みは、もともとエンジニアの小林が、各自の PC 上で Jicoo の作法に合ったレビューができるようにつくったものです。それを私が共通のサーバー側に移して、PR（コードの変更を取り込む前の提案）が更新されるたびに AI がレビューするようにしました。

ところが、AI の利用料が想定よりずっと大きかった。一時は、人を雇っているくらいのコストにまで膨らみました。

そこで、人間の側でできることはやる余地を残して、コストとのバランスを取ることにしました。コストの最適化に舵を切ったのは、かなり早かったと思います。当時は、トークン（AI の利用量の単位）をたくさん使う人ほどすごいと評価されるような空気がありました。でも、お金の使い方を変えるのは、経営者でないと手をつけにくい。メンバーには仕組みを何度も変えて申し訳なかったのですが、その後 AI の利用料はどんどん上がっていったので、今となっては正解だったと思っています。

今は、レビューを 2 段にしています。

• まず各メンバーが、定額プランの AI で手元のレビューを通す。従量課金の利用料や、サーバーでの実行費用を抑えるためです。

• ただ、手元のレビューは、AI に渡す情報や PC の環境で品質に差が出ます。なので最終チェックとして、サーバー側で、実装に使うものより性能の高いモデルを、統一された環境で走らせます。

• 上限がないと際限なく課金されるので、1 回のレビューにかけられるコストにも上限を設けています。

使うモデルも固定していません。「この作業にはこのモデル」という対応表は持たず、必要な品質を満たす候補の中から、完了までの総コストがいちばん小さい組み合わせを選ぶ、というルールだけを決めています。総コストには、キャッシュが効くか、やり直しがどれだけ起きそうか、別の AI に仕事を引き継ぐときの説明の手間まで含めます。仕組み自体も、Claude と Codex のどちらでも動くようにしてあります。

任せる範囲は、変更ごとに 3 段階で決める

AI に任せる範囲は、変更ごとに 3 段階で判定しています。AI が自律で完結するもの、人間の確認を待ってから AI が実装するもの、人間が主導するもの。見るのは次の 4 つです。

1. 既存の機能からどれだけ離れているか

2. 認証や課金のように、間違えると損害が大きい領域に触れるか

3. 変更が及ぶ範囲の広さ

4. 元に戻せるか

どれか 1 つでもリスクが高ければ、人間主導にします。この判定は AI 自身にもさせて、結果を変更ごとの仕様書に残します。

それでも判断に迷う場面はあります。たとえば、誰かがつくった試作品を引き継ぐときです。どこまで人が確認すべきか、その線引きはいまも難しいところです。

人間が一度答えた判断は、記録として残しています。AI が次に同じ問題にぶつかったら、その記録を再利用させる。同じ質問を人間に何度も投げさせないためでもあり、AI に判断をでっち上げさせないためでもあります。

仕様は、すべてリポジトリに置く

Slack でのやりとりや口頭の合意は、正式な仕様として扱いません。AI は会話の外にある事情を知らないからです。

各機能が今どう動くべきかを書いた仕様書と、変更ごとの仕様書を、コードと同じ保管場所（リポジトリ）に置き、そこから確認項目まで機械的につくります。起票した人も、AI も、エンジニアも、同じ文書を見て話せる。この共通言語があるから、コードを書かないメンバーも開発に加われるようになりました。

バグ修正では、修正前に失敗し、修正後に成功するテストを、AI に必ず示させています。示せないときは、PR をつくらずに人間へ戻します。「直しました」と言われても、それだけでは本当に直ったのか分かりません。修正前に失敗すれば、バグが実際に起きていると分かる。修正後に成功すれば、直ったと分かる。その両方を確かめるためのルールです。

人間のコードレビューは、やめた

人間によるコードレビューは、やめました。AI が書く量を、人間がすべて読むのは無理です。それに、人間のレビューはもともと精度が高くありません。実際、人間がコードを書かなくなってからのほうが、バグは減りました。

では、何を拠りどころに信用しているのか。基本は、テストの内容と結果です。テストの中身が意図と合っていて、結果が正しければ、信用する。ただし、データベースの構造が変わる変更は別です。壊れると元に戻すのが大変なので、そこは今もエンジニアが自分の目で見ています。セキュリティ的に危なそうだと感じたときは、コードを読むより先に「これ、本当に問題は起きない？」と AI に聞いて、根拠を説明させる。そういう使い方も、チームの中で定着してきました。

数字で見ると

本当にバグは減ったのか。リポジトリの履歴から、マージ（本番のコードに取り込むこと）した PR の変更箇所が、その後 60 日以内に小さなバグ修正で書き換えられた割合を集計してみました。

• 2025 年 1〜2 月（人間が書く）: 29.5%

• 2025 年 3 月〜2026 年 3 月上旬（Devin、Cursor などの補助ツールを使う）: 19.0%

• 2026 年 3 月中旬〜7 月（AI が書き、ハーネスで管理する）: 11.0%

ハーネスを入れた翌週から、マージされる PR の 8 割前後に AI が関わるようになり、8 月以降はほぼすべてです。区切りは違いますが、前年の同じ 3〜7 月どうしで比べても、14.1% から 11.4% に下がりました。

PR の本数は、前年の同じ時期の 2 倍になっています。PR を出しているメンバーの人数はほとんど変わっていないので、1 人あたりの月間マージ本数は、AI を使う前の約 9 本から、この夏には約 35 本と、4 倍になりました。

もちろん、AI に書かせ始めた時期とハーネスを入れた時期は重なっているので、どちらの効果かは数字だけでは切り分けられません。ただ、ハーネスなしで AI に書かせていたら、こうはならなかったと思います。エンジニアたちの実感とも、この数字は合っています。

コードを細かく知らなくても、速く、大きな不具合なく

この変化をいちばん象徴しているのが、あるエンジニアの働き方です。彼女は、Jicoo のコードを細かく把握する前に、AI 中心の開発に移りました。

調査や実装は、AI のほうが速く、正確なことが多い。それでも以前は、Jicoo ならではの事情を踏まえた判断は、人間のほうが正しくできていました。今はそうした判断もハーネスに組み込んでいるので、作業の中心は AI で、人間は「何をやるか、やらないか」を判断する。仕事の仕方そのものが変わってきていると、プロダクトオーナーとして横で見ていて感じます。

最近、彼女が手がけたのは次の 2 つです。

• 社内向けのプラン変更ツール: Jicoo は基本的に、お客様ご自身で契約やプランの変更をしていただくサービスです。ただ、サポートが必要なケースでは、カスタマーサクセスがエンジニアと一緒に対応していました。お客様が増えて個別対応も増えてきたので、カスタマーサクセスが社内専用の画面で契約や変更をできるようにしました。要件をカスタマーサクセスに聞いて AI に伝えるだけで、簡単に実装できています。

• 予約ページの表示の高速化: 調査も修正方法の検討も AI 中心で進め、問題の箇所でデータベースからデータを読み出す回数が 1/41 になりました。設計を AI に図解してもらい、実装してもらって、テストが通ったらリリース。3 時間でリリースまで持っていけました。

AI との向き合い方も、見ていて面白いところです。課題や PR のリンクを渡して「これは何をすればいいのかを簡単に説明して」と頼むところから始める。あるときは、ある変更のあとのデータベースの状態を前後で並べて見てもらっていました。すると AI は、変更前後の同じ曜日を比べて数値が変わった理由を説明し、そのうえで「ただ、1 つ気になることが見つかりました」と、注意したほうがよい点を自分から挙げてきた。まだ 1 日分しか見られていないので傾向は判断できない、と断ったうえで、いつまでにどちらの対策を選ぶか決めておくと安心だ、と選択肢を示し、インフラ担当に共有する下書きまで申し出てくれた。決めるのは人間ですが、判断に必要な材料はここまで揃うようになっています。

コードを読まずに「これで大丈夫」と判断するときの手がかりは、仕様とテストです。仕様は、既存の仕様と照らして不自然でないか、期待どおりかを見る。テストは、内容が意図と合っているかを確かめたうえで、結果が OK なら大丈夫と判断する。それでも大きな不具合を出さずに済んでいるのは、変更のたびに自動で走るチェック（CI）の中で AI がレビューし、不具合を見つけてくれるからです。本人の体感では、開発のスピードは 3 倍くらいになったそうです。

自分で書いたものを、自分でレビューさせない

実装したときの会話の続きでレビューさせると、AI は自分の判断を追認しがちです。そこで、レビューはそれまでの会話を引き継がない、まっさらな状態で実行させ、そうなっているかを記録で機械的に確かめています。これは小林がつくった仕組みです。独立性を決めるのは、使うモデルが同じかどうかではなく、前の会話を引き継いでいないことです。

この仕組みができる前は、手元で同じモデルにレビューさせていて、手戻りがそれなりにありました。

指摘の重大度は、「マージを止めるべき問題」と「止めなくてよい気づき」の 2 段階だけにしています。書き方の好みや褒め言葉、範囲の広すぎるつくり直しの提案は出させません。指摘の修正も AI が行いますが、自動で直す回数には上限があり、超えたら人間に戻します。また、指摘が依頼された挙動そのものを変えるものなら、AI は実装せずに人間に確認します。レビューを通すために、仕様のほうをずらさないためです。

2 段階にしてからは、細かい指摘のたびに AI が人間に確認してきたり、修正が止まったりすることが目に見えて減りました。重要な指摘に意識を向けやすくなり、バグの防止にも、開発のしやすさにもつながっています。

品質確認（QA）の実行も、AI に任せる

それまでも、確認項目を AI で自動作成することはやっていました。すると今度は、確認の実行がボトルネックになります。ここが速くならないと、開発自体も速くなりません。今の AI の水準なら、実行もある程度任せられるのでは、と考えました。

最初は、決まった操作を再生する自動テストツール（Playwright）で自動化していました。ところが、画面のラベルが変わるたびにテストを直す必要があり、メンテナンスが煩雑でした。そこで思い切って、AI 自身がブラウザを操作して仕様どおりかを確かめる、エージェント型の QA に舵を切りました。PR ごとに確認用の環境が自動で立ち上がり、AI の判定はスクリーンショット付きで残ります。

AI の QA の質を担保するために、社内の優秀な QA 担当者のやり方を AI に学ばせました。料金プラン改定の案件で、担当者が見つけた多くの不具合を材料にして、指摘の観点や、どこまで確かめれば十分かという目安を抽出しました。目指したのは、人間の QA の邪魔になるものではなく、補完して、QA の担当者が助かるものです。

見た目の良し悪しのように主観が入るもの、課金の承認、設計の判断が要るものは、最初から人間の確認項目として切り出しています。人間向けの確認手順は、コードを読めない人でもそのまま実施できる言葉で書きます。

人間の QA にしかできないことも、はっきりしてきました。実機での確認と、触ってみて「なんか変だな」と感じるところです。仕様どおりかは AI でも確かめられますが、その違和感に気づくのは、まだ人のほうが得意です。未知の組み合わせを探す探索的なテストも、まだ人間の仕事です。

Figma は、唯一のよりどころではなくなった

デザインも、リポジトリにあるコードを起点に Figma の画面をつくる方針にしました。デザイナーからは「デザイナーにしかカバーできないものがある」という声があり、それは正しいと思います。でも、コードを起点にしたほうが、デザインシステムに忠実なデザインになる。プロダクトとして良いものを優先して、UI の設計はある程度 AI に任せる方向にしました。

とはいえ、新しい画面を試作するなら Figma のほうが速い。今は Figma を使わない進め方が 6 割、使うのが 4 割くらいです。

ビルダー：コードを書かずに、1 人でプロダクトマネージャーの役割を担う

コードを書かずに、起票から確認までを自分で進める人を、私たちは「ビルダー」と呼んでいます。今動いているのは、主にカスタマーサポートとカスタマーサクセスのメンバーです。チャットサポートや商談で、実際の顧客の声を聞いている人たちです。

以前の彼らの仕事は、顧客の声を聞いて起票するところまででした。今は、課題管理ツール（Linear）の課題に「AI に任せる」ラベルを付けるだけで、AI が実装して PR をつくります。PR ごとに確認用の環境が立ち上がるので、起票した本人がそのまま動作を確かめられる。リリースの判断はエンジニアがしますが、それ以外は 1 人で完結します。ほとんど 1 人で、プロダクトマネージャーのような役割をこなせるようになりました。

ビジネスサイドだけで、今も 1 日 1 件くらいのペースでバグ修正がリリースされています。試作も、それに近い形で進んでいます。ビルダーが起票した課題にも、先ほどの 3 段階の判定がそのままかかります。認証や課金に触れるものは、誰が起票しても人間主導です。

一番効いたのは、起票から実装までを一続きにして、AI に仕事を渡す手間を小さくしたことです。課題管理ツールの中で、すごく簡単に AI に任せられる仕組みを最初につくった。敷居がすごく低くなったのだと思います。

流れは次のとおりです。

1. 起票する: 決まったテンプレートで起票します。書くのは、何が起きているか、何を実現したいか、どんな制約があるかだけ。実装の方法は書きません。どの機能の話か分からなくてもよく、それを特定するのは AI の仕事です。

2. AI に任せる: 「AI に任せる」ラベルを付けると、仕組みが課題を読み取り、内容を振り分けます。調査だけで済むものは、結果を課題へのコメントで返します。

3. 実装する: AI が変更ごとの仕様書をつくり、実装して、PR を出します。

4. レビューと確認: AI のコードレビューと、AI による QA が走ります。人間の判断が要るものは、人間が確かめます。

5. 結果を戻す: PR がマージされたり取り下げられたりすると、その結果が課題に自動で反映されます。マージするのは人間だけです。

エンジニアの仕事も変わりました。ちょっとしたバグ修正をビルダーが拾ってくれるので、エンジニアは重めの課題に時間を割けるようになりました。レビューも AI がやるので、エンジニアの手間はほとんど増えていません。ただし、ビルダーの PR でも、データベースの構造を変える処理だけはエンジニアが必ず見ています。データまわりは、後から取り返しがつかないことがあるからです。

ラベル 1 つで AI が動く以上、安全策も必要です。課題の文章をそのまま AI に渡すと、AI への指示を紛れ込ませることができてしまいます。なので、AI に渡してよい項目をテンプレートで決めておき、その項目だけを渡しています。怪しい文が入っていたら、AI に判断させずに止めて人間に戻します。AI を動かせる人やエージェントも限定しています。AI が実行する手順書の攻撃対策は、エンジニアが意識して入れたものというより、AI が実装の過程で入れてくれたものです。ハーネスが整っていたからこそだと思います。

ループ：人が課題を渡さなくても、改善が回り続ける

課題の入口は、人間の起票だけではなくなりました。

顧客の声が、そのまま課題になる

もともとは、私がプロダクトオーナーとしてやっている情報収集、分析、企画、管理の PDCA を、ノウハウごと自動化できないかと考えたのが始まりです。

今は、サポートチャットの会話を毎日 AI が読み、同じ要望をまとめて起票します。会話の本文そのものは残さず、AI の要約と、個人情報を伏せた抜粋だけを残します。リリースされたら、どの声に応えたのかを課題に記録し、サポート担当が顧客に返信するためのメモまで用意されます。

人間が必ず関わるのは、課題の却下、PR の承認、顧客への返信の 3 つです。課金や認証、個人情報に関わる声は、AI の判定よりも優先して、人間が主導する側に回します。すべての工程に停止スイッチもあります。

本番のエラーも、課題として戻ってくる

本番環境で起きたサーバーエラー（500 エラー）を AI が調べて、修正の PR までつくる仕組みもあります。対象は、コード側の不具合だけです。外部サービスやインフラが原因のものはコードを直しても解決しないので、AI に PR をつくらせても、意味のない変更が増えるだけだからです。この仕組みをつくる過程では、AI のコードレビューから、エンジニアも知らなかった不具合のパターンを何度も指摘されました。

ログに含まれる個人情報や認証情報は、課題にする前に伏せています。既定では「報告だけ」で、自動で PR までつくるのは条件を満たしたものに限っています。つくられた PR も下書きのままで、取り込むかどうかは人間が決めます。

直したあとも、AI が関わった PR がマージされたら、本番のエラー率や応答時間を前後で比べています。悪くなっていれば元に戻す PR の下書きを AI がつくりますが、自動ではマージしません。データが足りないときは、無理に白黒をつけず「判断できない」として扱います。このあたりは、まだ試行錯誤しながら改善を続けています。

自動メンテナンス

ループの代表が、毎朝の定期点検、自動メンテナンスです。平日の毎朝、AI がリポジトリ全体を点検して、リンク切れのドキュメント、仕様とコードのずれ、足りないテスト、何度も出るレビューの指摘などを見つけ、課題にして自分で直します。

変更を自動で取り込んでいいかは、変更の種類ごとに決めています。ドキュメントやテストの補強のように、プロダクトの動きに直接影響しない種類なら、条件を満たせば人間を介さずにマージしていい。実際、この点検から出た PR の半分以上は、人の手を介さずにマージされています。

ただし、条件は厳しくしています。

• リスクが低く、振る舞いを変えず、人間の判断待ちがなく、必須のチェックがすべて通っているものだけを自動でマージします。

• マージを実行するのは、実装する AI とは別の、マージ専用のアカウントです。書く役とマージする役を分けています。

• 失敗した課題に自動で再挑戦するのは数回までです。人間の判断が要る課題は、人間が解除するまで止まったまま。そうした「人間待ち」は、毎朝 Slack でまとめて通知されます。

ここには失敗もありました。最初は、重要でない、簡単にできる改善ばかりに手が伸びて、重要な改善が後回しになっていました。マージのたびに人の確認も発生して、技術的負債を楽に減らしていくはずの仕組みそのものが、むしろ負債になりかけていた。

そこで、何をするにも目標をはっきりさせ、それが全体の目標に合っているかを確認するプロセスを入れました。直した件数ではなく、残っている負債の量を毎日測り、課題ごとに、AI に「どの指標をどこまで動かすか」を宣言させています。宣言できないものは、自動では回しません。今は解消に向かっています。人間のマネジメントと同じだな、と感じました。

人間の手直しから、AI が学ぶ

AI が関わった PR で、AI のあとに人間が手で直した箇所を集めて、種類ごとに分類しています。文言の調子、機械的なチェックのすり抜け、ロジックの誤り、仕様からのずれ、テストの抜け、といった具合です。同じ種類が繰り返されたら、自動メンテナンスの課題になり、機械的なチェック、AI 向けの手順書、ドキュメントのどれかに取り込みます。人間が一度直したことを、次から AI が繰り返さないようにするためです。根拠が足りないものや、方針の担当者が決めるべきものは、AI には決めさせず、人間に引き継ぎます。

ループを監視するループ

仕組みそのものがうまく回っているかは、毎週の監査で確かめています。見るのは次の 3 つです。

• 本番に不具合が漏れた割合

• マージした PR 1 本あたりに、人間がどれだけ手を入れたか

• 起票からマージまでにかかった時間

品質と、人の手間と、速さを、必ず並べて見ます。1 つのスコアにまとめて良し悪しを決めることはしません。

見つかった問題は、計画の課題として起票するところまでにしています。AI に自動で直させないのは、まだ実現できるかを確かめている段階だからです。AI のワークフローに移すときは、まず小さく回し、結果を見て、また回す。最初は人間がループの中に入る「Human in the loop」で回し、人間が介在しなくても問題ないと確認できてから、外から見守るだけの「Human on the loop」に移す。そういう順番で進めています。

このやり方のデメリット

正直に書くと、デメリットもあります。

一番大きいのは、仕事の進め方を変え続けないといけないことです。これは、私たちが小さい組織だからできている面があります。エンジニアが 100 人、1,000 人いる組織なら、変えるだけで、政治的にもリソース的にも相当な力が要るはずです。人がやっていた仕事そのものを置き換えていくので、その苦労も出てくると思います。

もう 1 つは、ハーネスの改善に開発リソースを割く、という意思決定が要ることです。機能開発だけを見ていると、後回しになりがちです。そこを経営として決め切れるかが、分かれ目だと思います。

そして、ハーネスの出来が、そのまま品質に出ます。ハーネスが悪くなれば、プロダクトもどんどん悪くなっていく。設計に穴があれば、そこがセキュリティの穴になったり、性能が悪化したりする。だから、ハーネス自体を悪くしないように、常に気をつけていなければいけません。

責任の所在も、決めておかないと曖昧になりがちです。Jicoo では、コードの品質はハーネス（みんなでその都度直す）、仕様の品質は実装する人、テストの品質はテストの担当者、と決めています。

これから

チームのエンジニアは、自分でコードを書く時間がゼロになりました。その代わりに、AI が出してきたものが合っているかを理解するために AI と会話したり、仕様を決めたり、既存の仕様を理解したりすることに時間を使っています。エンジニアの仕事は、コードを書くことから、AI に何をさせて何をさせないかを決め、その判断を仕組みに落とすことへ移ってきたと感じています。

同じことに取り組もうとしている方に伝えたいのは、2 つです。1 つは、ハーネスを育てることに時間を使うこと。結局、そこが一番効いてきます。もう 1 つは、メンバー全員にルールを理解してもらい、一緒に取り組むこと。仕組みだけ整えても、チームが同じ方向を向いていなければ回りません。

私たちが目指しているのは、顧客の要望や不具合を、できる限り速く解消することです。カスタマーサクセスのスピードを、自動化で上げていく。そして空いた時間とリソースを、会社として挑戦したい新しいことを深く考え、試作する時間に回したい。ハーネスとループは、そのための仕組みです。