株式会社Helpfeelのご紹介 ─ Gyazo・Helpfeel・Cosense

株式会社Helpfeelは、様々なプロダクトを作っています。全世界で2000万人以上が使っているスクリーンショット共有ツール「Gyazo」、自己解決AIシステムの「Helpfeel」、そして私が担当しているWikiサービスのCosenseです。今回の発表資料もCosenseで動いていて、複数人で同時編集できたり、関連ページが自動で並んだり、様々なことができます。

Cosenseは、Helpfeel自体のFAQデータを書くための編集画面にもなっています。小売・金融・保険・メーカーなど幅広い業種に導入され、最近は地方銀行やインフラ系の顧客が増えています。だからこそ、Helpfeelは「bugのない開発」を目指しています。

「人を、信じたい」 ─ AI時代に増えた登場人物

ここ1年半ほどで、開発の登場人物にAIが加わりました。私のようなPdM、開発者、そしてAIエージェント。この構成のもとで、AIや人が信じられなくなってきているという課題があります。

直接AIを使う分にはまあまあ信じられるのですが、間に別の人を挟むと難しくなります。 私がいて、開発メンバーがいて、その先にClaude Codeがいる。ショベルカーの先端に筆をつけて字を書くような、リモートコントロールのさらにリモートコントロールのような状態です。その状態でAIにコードを書かれ、プルリクエストの説明もAIで書かれ、レビューしてほしいと言われると、なかなか辛いものがあります。

この「信じられなさ」を、5つに整理しています。開発者とAIエージェントの間で何をやりとりしていたのかを知りたい。AIが出力するコードの品質を上げたい。最終的に作られたコードを、自分が正しく理解したい。開発メンバーが正しく要件を理解しているかを知りたい。自分がどういう観点でコードレビューしているかを、開発メンバーに知ってほしい。これらがクリアできれば、人やAIを信頼できるのではないか、という発想です。

2025年以前は、セルフレビューの内容をレビューしてもらうことで、判断力が引き継げるレビューが成立していました。しかしAIが出てくると、内容を把握しないまま作られたものが「動きました」という状態になり、それが成立しなくなります。あわせて、AIによる開発でプルリクエストが巨大化しているという実感もあります。1人が出すプルリクエストの数はあまり増えていないものの、1つあたりのサイズがどんどん大きくなっていると感じています。

弊社では、現在このようにサイズの大きいプルリクエストが来ても対応できています。本日は、その要因となっている、今年2月頃から作成した3つのAgent Skillについてお話します。

Agent Skill ❶：codex-consultation

1つ目は、AIエージェント同士に激しい仮説・反論・再検証をやらせる「codex-consultation」というskillです。「相談して」という軽いトリガーで起動します。

きっかけは、Claude Codeで実装したコードにCodex CLIでセカンドオピニオンをさせると、多くのbugが見つかり、80点程度のコードが90点程度まで上がると気づいたことでした。ただし、私自身がClaude CodeとCodexの間のコピペ係となり、板挟みになる問題がありました。たとえばClaude Codeと「これはスクリーンショット向けの機能だからPNGだけ対応すればいい」と決めたコードをCodexに見せると、「なぜJPEG対応しないのか」と指摘され、その事情説明をいちいち行う必要がありました。

そこで、Claude CodeとCodexを直接やりとりさせる構成を「批判的思考の連鎖」として整理しました。Claude Codeには「問題解決しろ。自分の見解を示しつつ指示を出せ。」と役割を与え、Codexには「知的好奇心を持て。指示されたことはやるし、されていないこともやる。指示や前提そのものを疑って検証しろ。」と指示します。その上でClaude Codeに、中間管理職としての度量を持って、指示していないことまで書かれたレポートを1つずつ吟味し、報告書を書かせます。これにより、正確性と網羅性を両立したレポートが得られます。

さらに、「相談して」「確認して」「協力して」といった穏やかな言葉の意味を、このskillで上書きすることもしています。これらの言葉をAgent skillで乗っ取ることで、Claude CodeとCodexの間ではそれらが激しい相互検証を意味するようになります。必要に応じて二往復までやりとりさせると、多くのbugを見つけることができます。

レビュー系のskillは、観点のリストを渡して脆弱性チェックをしたりすると思うのですが、そういったものがなくてもかなりレビューができます。観点リストに基づいたチェックを行うskillと組み合わせて使うと、その精度がさらに増強されるような挙動になります。

Agent Skill ❷：conversation-context-exportとconversation-context-import

2つ目は、コードに残らない意思決定を引き継ぐための「conversation-context-export/import」というskillです。

AIと相談しながら開発を進めると、試行錯誤の過程や見つかった技術的制約など、多くの学びが生まれます。しかし、その部分が共有されないことが、レビューにおいて課題になります。コンソールのログをすべて取ってプルリクエストに添付する方法も試しましたが、結局読まれないという結論に至りました。「やったこと」はコードを読めば分かる一方で、「コードに残らなかった、やらないことと、その理由」こそ引き継ぐ価値があると考えました。

このskillでは、目的・却下した代替案・意図的に対応しないこと・発見された制約・新たに確認できた事実・難しかったことなどの分類でコンテキストを書き出します。なぜこの設定値にしないのかといった判断の理由が記録されるため、レビュー時に検索すれば分かる状態になります。

予想していなかったのですが、長いセッションでテキストを圧縮しないといけないときに、記憶が飛ばないです。特に飛びがちな「やらないと決めたこと」を重点的に書き出して引き継げるので、同じことを繰り返し伝えずに済みます。

Claude CodeとCodexが話し合い、私に報告せずに解決したbugも、この対話コンテキストに残ります。「Codexに確認してもらい、単純なbugであれば修正してください。解決方法が複数ある場合は私に質問してください」というプロンプトを愛用しており、その結果もログに残ります。

Agent Skill ❸：sanity-review

3つ目は、作業結果だけでなく、開発のプロセスがまともかどうかを確認する「sanity-review」というskillです。

私自身、AIが作ったコードの仕様を誤って理解していることがあり、その状態は顧客や社内への説明の観点で問題になります。また、対話コンテキストに書かれた「やらないことと、その理由」が本当に妥当なのか、改めて確認したいという狙いもあります。

sanity-reviewが主にチェックするのは3点です。概要欄がまともか（何を、なぜ、どうやって、どうなったのかを説明できているか）、概要欄と実装が一致しているか、そして実装の質がまともか。しっかり説明しているようでいて実装と合っていない場合、それはAIに出させたコードをコントロールできていないというシグナルになります。codex-consultationでbugを取った後に最後にsanity-reviewを回すと、追加でbugが見つかることが多いです。

出力例だと、変更前と後の動作がちゃんと説明できているか、問題解決と現状修正みたいなペアで書いてあるか、変更範囲が明確か、自分の言葉で説明できているか。そこが担保できた上で、説明と実装の整合性を見ます。実在のプルリクエストだと、以下と未満の条件を間違えていてダメ出しされたりします。

Codexが厳しくbugを指摘する一方で、Claude Codeが「理論的には正しいが、実際には限定的な問題だから大丈夫ではないか」とトリアージを手伝う挙動も見られます。説明と実装が一致していないことが指摘されることで、AIが出したものを自分で正しく理解できるようになります。

概要欄を宣言的に書くことがポイント

概要欄を宣言的に書くことがポイントです。確認項目が3つあるなら、3つの宣言を書くという考え方です。

たとえば「動作が変化していないか確認してほしい」と質問する代わりに、「動作は変更していない」「API v2を追加したが、後方互換性を維持するためv1の動作は一切変更していない」といった宣言を概要欄に書きます。その上でsanity-reviewをかけると、その宣言が嘘ではないかをcodex-consultationが疑って検証してくれます。FAQ形式でレートリミット時の挙動などを書くことや、「今はやらないこと」を書いておくこともポイントで、実装しないと決めたことが妥当かどうかまでチェックされます。

こうして、冒頭に挙げた「信じられなさ」の5つの観点が1つずつクリアされていきます。開発者とClaude Codeの間で何をやりとりしていたかはエクスポートしたコンテキストで分かり、コードの品質はcodex-consultationで上がり、最終的なコードの理解はsanity-reviewで担保されます。開発メンバーが要件を正しく理解しているかは、sanity-reviewに合格したきれいな実装と概要欄から分かり、自分のレビュー観点は、sanity-reviewの利用やAgent skillの中身を読むことで開発メンバーに伝わります。

社内で推奨している開発フロー

ここまでは、これらのSkillの概要と効果を紹介しました。

ここからは、これらを組み込んだ社内推奨の開発フローをご紹介します。よく使うプロンプトはIMEの辞書に登録しておき、Claude CodeとCodex CLIを併用します。

流れは次の通りです。まずAIと技術相談し、作りたいものを説明してAIに質問させます。このときplan modeを使うのが望ましく、実装前に不明点や懸念事項があれば何でも質問するよう指示しておきます。逆に言えば、この指示をしないと、不明点や懸念事項が多い状態のまま実装が進んでいることが分かります。Plan modeから実装したらすぐにbug修正を行い、プルリクエストを作成します。概要欄とレビューコメントの簡易的な見直しを行い、対話コンテキストをエクスポートし、sanity-reviewをかけます。sanity-reviewは対話コンテキストの中も見てレビュー報告書を作成します。その後レビューしてリリースします。

実装してからのbug修正と、簡単なAIレビューと、sanity-reviewのところで、確実にbugが見つかります。また、私も全然コードが理解できていないことが分かったりします。

その結果、人やAIをだんだんと信じられるようになりました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画はこちら
AI Engineering Summit Tokyo 2026

※動画の視聴にはFindyへのログインが必要です。

▼資料はこちら
正気を疑う技術 - bugのないvibe codingを目指して