「コードを書けない人」がプロダクトをつくる。Jicoo のハーネスとループのエンジニアリング

書くのは AI、判断するのは人間。Jicoo（ジクー） の開発チームが、この半年で組み上げた「ハーネス」と「ループ」を、CEO とエンジニア 2 名が振り返る対談です。始めたきっかけと AI に任せる範囲の決め方、人間がコードを読まなくなった今のコードレビューと品質確認（QA）、そしてビジネスサイドのメンバーが 1 人で不具合を直せる「ビルダー」と、人が課題を渡さなくても改善が回り続ける「ループ」まで。このやり方のデメリットも正直に話します。

登場人物

• 鈴木: 株式会社 Jicoo CEO / プロダクトオーナー
• 小林: エンジニア。本番環境で起きたエラーの自動修正、確認用環境、セキュリティを担当
• 小柳: エンジニア。AI が実行する手順の安全性と、変更を自動で取り込むかどうかの判定を担当

コードを書けない人も、開発に参加できるはず

── 始めたきっかけを教えてください。

鈴木: 2025 年の春に Devin のような AI 開発エージェントを試し、そのあと Cursor のようなコーディング補助ツールを使うようになりました。Cursor を使っていて、「これならコードを書けない人でもプロダクト開発に参加できる」と思ったのが出発点です。顧客の声をいちばん近くで聞いているサポートや営業が、自分で直せるようになる。そうなれば開発は速くなるし、採用の問いも「エンジニアを何人採るか」から「プロダクトに関われる人を何人にするか」に変わります。AI の性能も追いついてきたので、2026 年 3 月にハーネスの最初の土台を入れました。

── エンジニアのお二人に、抵抗はありませんでしたか。

小林: 正直、あまり不安はありませんでした。その時点で、AI エージェントのほうが自分より優秀だと思っていたので。コードの修正や、単純なデータベースの変更で済む開発なら、今はほぼ心配していません。ただ、複数の部品にまたがる移行のようなものは、まだ人が見たほうがいいと思っています。

小柳: 抵抗はなかったのですが、最初は信頼しきれず、AI がコードを書くたびに自分でテストしていました。今は設計から実装、テストまで AI に任せて、私は仕様どおりか、テスト結果が問題ないかを確認するくらいです。それでリリースまで問題なく進むので、不安はなくなりました。

ハーネスは「ガードレール」であり「AI の人格」

── 「ハーネス」を一言で言うと何ですか。

鈴木: ハーネスは、もともと馬につける馬具のことです。AI に安全に仕事をしてもらうための馬具、というイメージです。どこまで自分で走っていいか、どこで止まって人間に聞くか。AI にコードを書かせること自体は、もう難しくありません。難しいのは、書かれたものを誰がどう信用するかです。

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

小林: AI が変な方向に行かないためのガードレールですね。縛るというより、安心して走らせるためのものです。

小柳: 私は「プロジェクトメンバーとしての AI の人格」だと思っています。AI が間違えたら、メンバーに次から改善してもらうように、ハーネスを直すイメージです。

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

── 最初から今の形だったのですか。

鈴木: コードレビューを AI に任せる仕組みは、もともと小林さんが、各自の PC 上で Jicoo の作法に合ったレビューができるようにつくったものです。それを私が共通のサーバー側に移して、PR（コードの変更を取り込む前の提案）が更新されるたびに AI がレビューするようにしました。最初は実装もレビューも全部 AI に任せる設計でしたが、AI の利用料が想定よりずっと大きかった。そこで、人間ができることは人間がやる余地を残して、コストとのバランスを取りました。

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

小柳: 一時は、コストが人を雇っているくらいまで膨らんでいました。今はレビューを 2 段にしています。まず各メンバーが、定額プランの AI で手元のレビューを通す。従量課金の利用料や、サーバーでの実行費用を抑えられるからです。ただ、手元のレビューは、AI に渡す情報や PC の環境によって品質に差が出ます。なので最終チェックとして、サーバー側で、実装に使うものより性能の高いモデルを、統一された環境で走らせています。上限がないと従量課金で際限なく課金されてしまうので、レビューにかけられるコストにも上限を設けています。

使うモデルは、固定しない

── 作業ごとに、使う AI のモデルは決めているのですか。

鈴木: 「この作業にはこのモデル」という固定の対応表は持っていません。決めているのは、その作業に必要な品質を満たす候補の中から、完了までの総コストがいちばん小さい組み合わせを選ぶ、というルールだけです。総コストには、キャッシュ（一度読ませた内容を再利用して安く済ませる仕組み）が効くか、やり直しがどれだけ起きそうか、別の AI に仕事を引き継ぐときの説明の手間まで含めます。料金や残りの利用枠が確認できないときは、「いちばん安かった」とは報告させません。

仕組み自体も、Claude と Codex（OpenAI）のどちらでも動くようにしています。どちらか一方でしか回らない形にはしていません。

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

── AI に任せる範囲は、どう決めていますか。

鈴木: 変更ごとに、AI が自律で完結するもの、人間の確認を待ってから AI が実装するもの、人間が主導するもの、の 3 段階に分けます。見るのは次の 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 を使う前（2024 年秋〜2025 年 2 月）の約 9 本から、この夏（2026 年 6〜8 月）には約 35 本と、4 倍になっています。AI に書かせ始めた時期とハーネスを入れた時期は重なっているので、どちらの効果かは、数字だけでは切り分けられません。ただ、ハーネスなしで AI に書かせていたら、こうはならなかったと思います。

── お二人の実感と合っていますか。

小林: 実感どおりです。

小柳: 私も合っていると思います。人間が書いていた時期の数字は多いなと感じましたが、人間より AI のほうがミスが少ないという実感はあります。

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

── 小柳さんは、Jicoo のコードを細かく把握する前に、AI 中心の開発に移ったそうですね。最初はどう感じましたか。

小柳: AI がとても優秀で驚きました。AI の調査や実装は速く、正確なことが多かったのですが、それでも以前は、Jicoo のことについては人間のほうが正しく判断できていました。今はそうした Jicoo ならではの判断も、ハーネスに組み込んでいるので、作業の中心は AI で、人間は何をやるか、やらないかを判断するようになった。新しい仕事の仕方に変わっていっているなと感じています。

── 最近はどんな開発をしましたか。

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

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

── AI とは、実際にどんな会話をしているのですか。

小柳: 最初は、課題管理ツールの課題か PR のリンクと一緒に、「これは何をすればいいのかを簡単に説明してください」と、まず内容の説明をお願いしています。途中では、疑問に思ったことを質問したり、進捗を確認したりしています。「すでに過ぎた期間のデータも集計できる？」「今すぐ 7 日間のデータを取れる？ それとも計測が必要？」といった感じです。

ある変更のあとに、データベースの状態の推移を並べて見てもらったことがあります。AI は変更前後の同じ曜日を並べて比べ、数値が変わった理由を説明してくれました。そのうえで、「ただ、1 つ気になることが見つかりました」と、注意したほうがよい点を自分から挙げてくれたんです。まだ 1 日分しか見られていないので傾向は判断できない、とも添えていました。そして、いつまでに、どちらの対策を選ぶかを決めておくほうが安心です、と選択肢を示し、インフラ担当の方に共有する下書きもつくれます、と申し出てくれました。

── コードを読まずに「これで大丈夫」と判断するとき、何を手がかりにしていますか。

小柳: 仕様は、既存の仕様と照らし合わせて不自然なところがないか、「こうなっていてほしい」という期待どおりになっているかを確認しています。テストは、まずテストの内容が意図したものと合っているかを確認して、問題がなければ、実行結果が OK であることをもって「大丈夫」と判断しています。

── 大きな不具合を出さずに進められている理由は、何だと思いますか。

小柳: 変更のたびに自動で走るチェック（CI）の中で AI がレビューをしてくれて、そこで不具合を見つけてくれるからだと思います。

── 開発のスピードは、以前と比べてどう変わりましたか。

小柳: 体感で、3 倍くらい速くなったと思います。

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

── 自分で書いたものを、自分でレビューさせない仕組みもあるそうですね。

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

── 仕組みができて、何が変わりましたか。

小柳: この仕組みができる前は、手元で同じモデルにレビューさせていて、手戻りが今と比べると結構あったと思います。レビューの指摘を直すのも AI です。指摘の重大度を「止めるべき問題」と「気づき」の 2 段階だけにしてからは、細かい指摘のたびに AI が私に確認してきたり、修正が止まったりすることが減りました。重要な指摘に意識を向けやすくなって、バグの防止にも、開発のしやすさにもつながっていると感じています。

【解説】レビューの二段構え

Jicoo では、AI が書いた変更は、まず手元のレビューを通してから PR として出し、共通のサーバー側で最終チェックとしてもう一度レビューします。コストが際限なく膨らまないよう、1 つの PR にかけられるコストには上限があります。

レビューをする AI は、実装したときの会話を引き継がない、別の実行として動きます。独立しているかどうかは、使うモデルが同じかどうかではなく、「前の会話を引き継いでいないこと」で担保しています。そのうえで、サーバー側の最終チェックには、実装に使うものより性能の高いモデルを使っています。

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

品質確認の実行を、AI に任せる

── 品質確認（QA）の実行も、AI に任せるようになったそうですね。きっかけは何でしたか。

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

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

── AI の QA の質は、どう担保したのですか。

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

── 人間の QA にしかできないことは残っていますか。

小林: 実機での確認と、触ってみて「なんか変だな」と感じるところですね。仕様どおりかは AI でも確かめられますが、その違和感に気づくのは、まだ人のほうが得意です。環境の面では、外部サービスから届く通知（webhook）を、PR ごとの確認用環境にどう届けるかが、難しいところです。

【解説】AI による QA と、人間に残している確認

PR ごとに確認用の環境が立ち上がると、AI がブラウザを操作して、仕様どおりに動くかを確かめます。判定は、スクリーンショット付きで残ります。

一方で、見た目の良し悪しのように主観が入るもの、課金の承認、設計の判断が要るものは、最初から人間の確認項目として切り出します。人間向けの確認手順は、コードを読めない人でもそのまま実施できる言葉で書きます。画面に出てこない内部の ID や変数名は混ぜません。

未知の組み合わせを探す探索的なテストは、まだ人間の仕事です。決まった操作を再生する自動テストは、本当に重要な導線だけに絞りました。

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

── デザインの進め方も変わりましたか。

鈴木: デザインは、リポジトリにあるコードを起点に、Figma（デザインツール）の画面をつくる方針にしました。デザイナーからは「デザイナーにしかカバーできないものがある」という声があり、それは正しいと思います。でも、コードを起点にしたほうが、デザインシステム（色や部品などのデザインの共通ルール）に忠実なデザインになる。プロダクトとして良いものを優先して、UI の設計はある程度 AI に任せる方向にしました。ただ、新しい画面を試作するなら Figma のほうが速いので、今は Figma を使わない進め方が 6 割、Figma を使うのが 4 割くらいです。

ビルダーは、1 人でプロダクトマネージャーの役割を担う

── コードを書かないメンバーも、開発に加わっているそうですね。

鈴木: はい。私たちは「ビルダー」と呼んでいて、コードを書かずに、起票から確認までを自分で進める人のことです。今動いているのは、主にカスタマーサポートとカスタマーサクセスのメンバーです。チャットサポートや商談で、実際の顧客の声を聞いている人たちですね。以前は、顧客の声を聞いて起票するところまでが仕事でした。今は、課題管理ツール（Linear）の課題に「AI に任せる」ラベルを付けるだけで、AI が実装して PR をつくります。PR ごとに確認用の環境が立ち上がるので、起票した本人がそのまま動作を確かめられる。QA まで自分でできるわけです。リリースの判断はエンジニアがしますが、それ以外は 1 人で完結します。ほとんど 1 人で、プロダクトマネージャーのような役割をこなせるようになりました。

ビジネスサイドだけで、今も 1 日 1 件くらいのペースでバグ修正がリリースされています。試作も、それに近い形で進んでいます。コードを書けない人でもプロダクト開発に参加できるようにする、というのが最初からの狙いでした。

ビルダーが起票した課題にも、先ほどの 3 段階の判定がそのままかかります。認証や課金のように、間違えると損害が大きい領域に触れるものは、誰が起票しても人間主導です。

── 何が一番効きましたか。

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

仕様をすべてリポジトリに置いて、起票した人、AI、エンジニアが同じ文書を見て話せるようにしたことも大きいですね。

【解説】課題が PR になるまで

ビルダーが起票してから、PR ができるまでの流れを整理します。

1. 起票する: 課題管理ツールで、決まったテンプレートを使って起票します。テンプレートは「バグ報告」「機能の要望・企画」「調査・確認」の 3 種類です。書くのは、何が起きているか、何を実現したいか、どんな制約があるかだけ。実装の方法は書きません。どの機能の話か分からなくても起票してよく、それを特定するのは AI の仕事です。
2. AI に任せる: 課題に「AI に任せる」ラベルを付けると、数分以内に仕組みが課題を読み取り、内容を振り分けます。実装が必要なものは開発用の依頼に変換し、調査だけで済むものは、結果を課題へのコメントで返します。
3. 実装する: AI は、その変更で何をどう変えるかを書いた「変更ごとの仕様書」をつくり、実装して、PR を出します。
4. レビューと確認: PR には AI によるコードレビューが走ります。指摘の重大度は「マージを止めるべき問題」と「止めなくてよい気づき」の 2 段階だけで、指摘の修正も AI が行います。自動で直す回数には上限があり、超えたら人間に戻します。さらに PR ごとに確認用の環境が立ち上がり、AI がブラウザを操作して仕様どおりかを確かめます。判定はスクリーンショット付きで残ります。見た目の良し悪しや課金の承認のように人間の判断が要るものは、最初から人間の確認項目として切り出され、人間が確かめます。起票した人も、確認用の環境で実際の画面を確かめられます。
5. 結果を戻す: PR がマージされたり、取り下げられたりすると、その結果が課題管理ツールの課題に自動で反映されます。マージするのは人間だけです。

エンジニアから見たビルダー

── エンジニアのお二人から見て、ビルダーが PR を出すようになって何が変わりましたか。

小林: ちょっとしたバグ修正をビルダーの人たちが拾ってくれるので、すごく助かっています。その分、エンジニアは重めの課題に時間を割けるようになりました。レビューも AI がやってくれるので、こちらの手間はほとんど増えていません。

小柳: 私も、ビジネスサイドのメンバーが小さい修正を拾ってくれるので、重い課題に集中できるようになりました。

── ビルダーの PR で、リリース前に必ず見るところはありますか。

小林: ビルダーの PR で必ず見るのは、データベースの構造を変える処理です。データまわりは後から取り返しがつかないことがあるので、中身がおかしければ差し戻します。

ラベル 1 つで AI が動く、その安全策

── ラベル 1 つで AI が動くのは、危なくないですか。課題の文章に、悪意のある指示が紛れ込むこともありえます。

小柳: 課題の文章をそのまま AI に渡すと、AI への指示を紛れ込ませることができてしまいます。なので、AI に渡してよい項目をテンプレートで決めておき、その項目だけを渡しています。それでも怪しい文が入っていたら、AI に判断させずに止めて、人間に戻します。AI を動かせる人や、ハーネスの中のエージェントも限定しています。

AI が実行する手順書に、不正な命令を紛れ込ませる攻撃への対策や、実行先の制限が入っているのも、実は私が意識して入れたわけではありません。AI が実装の過程で入れてくれました。ハーネスが整っていたおかげだと思います。

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

── 課題の入口は、人間の起票だけですか。

鈴木: 課題の入口は、人間の起票だけではなくなりました。もともとは、私がプロダクトオーナーとしてやっている情報収集、分析、企画、管理の PDCA を、ノウハウごと自動化できないかと考えたのが始まりです。今は、サポートチャットの会話を毎日 AI が読み、同じ要望をまとめて起票します。人間が必ず関わるのは、課題の却下、PR の承認、顧客への返信の 3 つです。課金や認証、個人情報に関わる声は、AI の判定よりも優先して、人間が主導する側に回します。

【解説】顧客の声を課題にする仕組み

• 毎朝読んで、まとめる: 毎朝、サポートチャットの会話を AI が読み、要望を抜き出します。同じ要望はひとつにまとめて起票し、「AI に任せる」ラベルを付けるところまで自動です。
• 生の会話は残さない: 会話の本文そのものは残しません。残すのは、AI による要約と、個人情報を伏せた抜粋だけです。
• お金と個人情報は人間へ: 課金・認証・個人情報・料金・法務に関わる声は、必ず人間主導に回します。この振り分けは、AI の判定より優先されます。
• 人間が関わる 3 点: 振り分けの却下、PR の承認、顧客への返信の送信は、必ず人間が行います。
• 対応したことを伝える: リリースされたら、どの声に応えたのかを課題に記録します。サポート担当が顧客に返信するためのメモや、更新履歴の下書きまで用意されます。
• いつでも止められる: すべての工程に停止スイッチがあり、書き込みを伴う工程は、既定では報告だけにしてあります。

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

── 本番環境で起きたサーバーエラー（500 エラー）を AI が調べて、修正の PR までつくる仕組みもあるそうですね。どんなエラーでも直すのですか。

小林: 対象はコード側の不具合だけです。外部サービスやインフラが原因のものは、コードを直しても解決しない。そこで AI に PR をつくらせても、意味のない変更が増えるだけなので。

── この仕組みのセキュリティを強化するときは、AI によるコードレビューで何度も指摘を受けたそうですね。AI のレビュアーに鍛えられた実感はありますか。

小林: 「こういう不具合も起きるのか」と、自分が知らなかったことを教えてもらうことはよくあります。

── エラーのログには、お客様の情報が含まれることもありますよね。

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

── 直したあと、本番で悪化していないかは、どう確かめていますか。

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

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

── 先ほど少し出た「ループ」は、具体的にはどんな仕組みですか。

鈴木: 代表的なのが、自動メンテナンス、つまり毎朝の定期点検の仕組みです。平日の毎朝、AI がリポジトリ全体を点検して、リンク切れのドキュメント、仕様とコードのずれ、足りないテスト、何度も出るレビューの指摘などを見つけ、課題にして自分で直します。人が課題を渡さなくても、改善が回り続ける。これが私たちの言うループの 1 つです。先ほどの、顧客の声を起票する仕組みも、同じようにループになっています。

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

本番のエラーから直す仕組みも、考え方は同じです。人が課題を渡さなくても次の仕事が生まれ、終わった結果がまた課題に戻ってくる。その輪を少しずつ増やしています。

── うまくいかなかったことはありますか。

鈴木: ありました。最初は、重要でない、簡単にできる改善ばかりに手が伸びて、重要な改善が後回しになっていました。マージのたびに人の確認も発生して、技術的負債（後回しにしてきたコードの問題）を楽に減らしていくはずの仕組みそのものが、むしろ負債になりかけていた。そこで、何をするにも目標をはっきりさせ、それが全体の目標に合っているかを確認するプロセスを入れました。直した件数ではなく、残っている負債の量を毎日測り、課題ごとに、AI に「どの指標をどこまで動かすか」を宣言させています。今は解消に向かっています。人間のマネジメントと同じだな、と感じました。

【解説】自動メンテナンスの 1 日

1. 点検する: 平日の毎朝、AI がリポジトリ全体を点検します。対象は、リンク切れのドキュメント、仕様とコードのずれ、テストが足りない箇所、機械的に直せる書き方の違反、レビューで繰り返し出る指摘などです。
2. 課題にする: 見つけたものは課題にまとめます。同じ種類のものは、ひとつにまとめます。
3. 少しずつ渡す: 優先度の高いものから、1 回に数件だけ AI に渡します。1 回に新しくつくる課題の数も渡す数にそろえ、課題が処理より速く積み上がらないようにしています。
4. 目標を宣言させる: 課題ごとに、どの指標を今の値からどこまで動かすか、どう確かめるかを AI に宣言させます。宣言できないものは、自動では回しません。
5. 条件をすべて満たしたものだけ自動でマージ: 人を介さずにマージしてよいのは、リスクが低く、プロダクトの振る舞いを変えず、人間の判断待ちの項目がなく、必須のチェックがすべて通り、変更が宣言した範囲の外に出ていないものだけです。1 つでも欠ければ、エンジニアのレビューに回ります。自動マージそのものも、明示的に有効にしない限り動きません。
6. 書く役とマージする役を分ける: マージを実行するのは、実装する AI とは別の、マージ専用のアカウントです。
7. 止まるべきところで止まる: 失敗した課題に自動で再挑戦するのは数回まで。人間の判断が要る課題は、人間が解除するまで止まったままです。こうした「人間待ち」の課題は、平日の朝に Slack でまとめて通知され、長く滞っているものは強調されます。

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

── AI の間違いは、どうやって次に生かしているのですか。

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

ループを監視するループ

── 仕組みそのものがうまく回っているかは、どう確かめていますか。

鈴木: 毎週、開発の流れ全体を監査しています。見るのは 3 つです。本番に不具合が漏れた割合、マージした PR 1 本あたりに人間がどれだけ手を入れたか、起票からマージまでにかかった時間。品質と、人の手間と、速さを、それぞれ見ているわけです。この 3 つは必ず並べて見て、1 つのスコアにまとめて良し悪しを決めることはしません。見つかった問題は、計画の課題として起票するところまでにしています。

── そこは、AI に自動で直させないのですか。

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

デメリット: ハーネスの出来が、そのまま品質に出る

── このやり方のデメリットは何ですか。

鈴木: 一番大きいのは、仕事の進め方を変え続けないといけないことです。これは、小さい組織だからできている面があります。エンジニアが 100 人、1,000 人いる組織なら、変えるだけで、政治的にもリソース的にも相当な力が要るはずです。人がやっていた仕事そのものを置き換えていくので、その苦労も出てくると思います。もう 1 つは、ハーネスの改善に開発リソースを割く、という意思決定が要ることです。機能開発だけを見ていると、後回しになりがちです。そこを経営として決め切れるかが、分かれ目だと思います。

小林: ハーネスの出来が、そのまま品質に出るところですね。ハーネスが悪くなれば、プロダクトもどんどん悪くなっていきます。なので、ハーネス自体を悪くしないように気をつけないといけません。

小柳: ハーネスの設計に穴があると、そこがセキュリティの穴になったり、性能が悪化したりするのが危ういところだと思います。責任の所在も、きちんとルールを決めておかないと曖昧になりそうです。Jicoo では、コードの品質はハーネス（みんなでその都度直す）、仕様の品質は実装する人、テストの品質はテストの担当者、と決めています。

コードを書く時間は、ゼロになった

── 今、コードを書く時間はどれくらいありますか。

小林: 自分でコードを書く時間は、ゼロになりました。今はほとんど、AI が出してきたものが合っているかを理解するために、AI と会話しています。

小柳: 私もゼロです。その分、仕様を決めることと、既存の仕様を理解することに時間を使えるようになりました。

── 最後に、同じことに取り組む人へ一言ずつお願いします。

小林: ハーネスを育てることに時間を使ってほしいです。結局、そこが一番効いてくるので。

小柳: メンバー全員にルールを理解してもらい、一緒に取り組んでもらうことが大事だと思います。

鈴木: 目指しているのは、顧客の要望や不具合を、できる限り速く解消することです。カスタマーサクセスのスピードを、自動化で上げていく。そして空いた時間とリソースを、会社として挑戦したい新しいことを深く考え、試作する時間に回したいと思っています。