Claude・Codexで社内アプリを20本以上作ってわかったこと｜半年で回した開発フローと引き継ぎの仕組み

想定読者

自社でAIを使った内製アプリ開発を検討している中小企業の経営者や情報システム担当者を想定しています。

既製のSaaS（クラウド型のソフトウェア）を使ってはいるものの、自社の業務フローに合わない部分が残っていて困っている方、かといって外部の開発会社に発注するほどの予算や時間の余裕もない、という方に向けて書いています。

要点

• 弊社では2026年4月から約半年で20本以上の社内アプリを開発し、そのうち6本を社外向けに公開しています
• 設計とコード生成をClaudeとClaude Codeが担い、Codexがコードレビュー役を務めるという役割分担で開発フローを回しています
• Obsidian（ノートアプリ）に作業ログ・失敗の教訓・ルールを残し、AIが次の作業に入る前にそれを読むことで、経験を引き継ぐ仕組みを作っています

半年で20本以上、社内でAIに何を作らせてきたか

2026年4月からの半年で20本以上（うち公開6本）という実績の内訳

弊社は2026年4月から半年ほどの間に、社内で使うアプリを20本以上開発してきました。

このうち、社外のお客様にもご利用いただける形に整えて公開したものは6本です。残りは社内の特定の業務のためだけに作った、いわば「一人用・一部署用」のツールで、公開を前提としていないため名称や中身の紹介は控えます。

この本数を見ると「よほど大規模な開発チームを抱えているのでは」と思われるかもしれませんが、実態は逆です。

これだけの数をこなせているのは、後述する開発フローとAIの役割分担、そして失敗を引き継ぐ仕組みがあってこそだと感じています。

重要なのは「本数の多さ」そのものより、「試すコストが下がったことで、小さな業務課題にもアプリという解決策を選びやすくなった」という変化だと捉えています。

設計からコード生成までのAIの役割分担

ClaudeとClaude Codeが担うアプリ設計・DB設計・コード生成

弊社の開発フローは、次の順序で進みます。

アプリ設計 → DB設計 → コード生成 → コード検証 → ベータリリース → バグ修正 → アプリ内チャット機能で利用者からバグを集める → 修正・改善 → 本番リリース

このうち、アプリ設計・DB設計（データベースの構造を決める工程）・コード生成の3つを、対話型AIのClaudeと、開発環境に組み込んで使うClaude Codeが担当しています。

まずClaudeに業務課題や欲しい機能を伝えて要件を整理し、画面構成やデータの持ち方の案を出してもらいます。この段階で「誰が」「何のために」「どのくらいの頻度で」使うのかを具体的に詰めることで、後工程の手戻りを減らしています。

設計が固まったら、Claude Codeにコードベースを直接触らせ、DBのテーブル設計から実際の画面・機能のコードまでを生成させます。

人間が最初から最後まで手でコードを書くのではなく、AIが生成したものを人間が確認・修正していく進め方です。

Codexをコードレビュー役に置く理由

生成されたコードは、そのまま本番に使うのではなく、別のAIであるCodexにレビューさせています。同じAIに設計からレビューまで一貫して任せてしまうと、自分が書いたコードの誤りに気づきにくいという傾向があります。

人間の開発現場で「書いた本人以外がレビューする」のが基本とされているのと同じ理由で、設計・生成を担うAIと、レビューを担うAIをあえて分けています。

Codexには、コードの誤りだけでなく、設計の意図から外れていないか、想定外の入力への対応が漏れていないかといった観点でもチェックさせ、指摘が出た箇所をClaude Codeに戻して修正する、というやり取りを何度か繰り返してからベータリリースに進みます。

ベータ公開からバグ修正、本番リリースまで

アプリ内チャットで利用者からバグを集める仕組み

コード検証を終えたアプリは、いきなり本番公開するのではなく、まずベータ版として限定的に使い始めます。

ここで重視しているのが、アプリ内にチャット機能を組み込み、使っている本人がその場で不具合や使いにくさを報告できるようにしていることです。

別のツールに切り替えて問い合わせるのは意外と手間がかかり、小さな不満ほど報告されずに埋もれてしまいます。

使っている画面の中から一言送れる形にすることで、些細な違和感も拾いやすくなり、実際の利用シーンに即したフィードバックが集まります。

修正・改善を経て本番リリースへ

集まった報告は優先度をつけて修正し、必要であればClaude・Claude Code・Codexの3者による設計〜レビューの工程に再び戻します。

一度作って終わりではなく、ベータ期間中に何度かこのサイクルを回すことで、実際の業務で使えるレベルまで品質を上げてから本番リリースに進みます。

この「小さく公開して、使いながら直す」進め方は、要件定義に時間をかけすぎず、実際の利用データを元に改善できる点が内製開発の強みだと感じています。

失敗の教訓をAIに引き継がせる仕組み

半年で20本以上という本数を回せている背景には、開発フローだけでなく、プロジェクトの経験をAIに引き継がせる仕組みがあります。

AIとのやり取りは基本的にセッション（対話のひとまとまり）ごとに完結してしまい、放っておくと同じ失敗を別のプロジェクトで繰り返してしまいます。これを防ぐために、弊社ではノートアプリのObsidianを使っています。

Obsidianに残す3種類のノート

Obsidianには、大きく分けて3種類のノートを残しています。

1つ目は「作業ログ」で、その日どのプロジェクトで何をしたか、どんな判断をしたかを記録します。

2つ目は「失敗の教訓」で、うまくいかなかった実装方法や、後から手戻りが発生した設計判断を、原因と合わせて残します。

3つ目は「ルール」で、失敗の教訓から一般化できるものを、次から必ず守るべき決まりごとの形にまとめ直したものです。

作業ログは日々の記録、失敗の教訓はその日限りの反省、ルールはプロジェクトを横断して適用される決まりごと、という役割分担です。

ルールをまとめる際に意識しているのが、「やること」だけでなく「やらないこと」も明文化することです。

手順やベストプラクティスといった「やること」は書き残されやすい一方、過去に問題を起こした特定のやり方や、一見よさそうでも避けるべき選択肢といった「やらないこと」は言語化されないままになりがちです。

「この方法は使わない」という禁止事項をルールとして残しておくことで、AIが同じ失敗につながる選択肢を最初から候補から外せるようになり、教訓を引き継ぐ精度が上がると感じています。

AIが次の作業前にノートを読む運用の作り方

この仕組みが機能する条件は、AIに新しい作業を依頼する前に、必ず関連するノートを読ませることです。

弊社では、新しいプロジェクトを始める際やタスクに着手する前に、Claude CodeにObsidian内の「ルール」ノートと、関連しそうな過去の「失敗の教訓」ノートを読み込ませてから作業を始めるよう運用しています。

読み込みを工程の一部として組み込んでおかないと、AIは毎回「初めて聞く話」として作業を進めてしまい、過去の失敗が活かされません。

逆に言えば、この読み込みさえ徹底できれば、担当者が変わったり、久しぶりに触るプロジェクトであっても、AIが過去の経緯を踏まえた提案をしてくれるようになります。

Q-Toolsの実例と、中小企業がこの方法を取り入れる際の注意点

WebRepo・Forms・mails・Manulog・Drive・Contentsに共通する開発の考え方

現在公開している6つのサービスには、いずれも「既製のSaaSにはあと一歩足りない部分を、自社の業務課題を起点に埋める」という共通の考え方があります。

たとえばWebRepoは、検索エンジンだけでなく生成AIにも正しく評価されるサイトを目指し、検索順位の計測からAIによるページ診断、sitemap.xmlなど各種ファイルの生成までを一気通貫で行えるようにしたものです。

Forms・mailsは、コードを書かずに条件分岐付きのフォームを作れる仕組みと、購読者管理から配信・開封確認までをひとつの画面で完結させたいというニーズから生まれました。

Manulogは、紙やローカルファイルに散らばりがちな業務マニュアルを組織・チーム単位でクラウドに集約し、AIによる本文生成や要約・校正も支援します。

Driveは、データの保管場所を用途やコンプライアンス要件に合わせて選べるファイル共有サービスです。

Contents（ヘッドレスCMS）は、サイトやアプリに配信する記事やお知らせなどのコンテンツを一つの管理画面にまとめ、API経由で複数の画面に配信できるようにしたものです。いずれも「自社で困っていたことをまず自社用に作り、使いながら磨いた」という点が共通しています。

内製開発に向くアプリ・向かないアプリの見分け方

同じやり方を他社が取り入れる際に注意したいのは、すべての業務課題が内製開発に向いているわけではないという点です。

内製開発に向くのは、利用者が限られていて要件がある程度絞り込める業務や、既製のSaaSでは細かい調整ができずに現場が我慢して使っているような業務です。逆に、不特定多数が使う複雑な決済処理や、法令対応の要件が頻繁に変わる分野は、既製の専門サービスを使うほうが安全で、開発・保守のコストも見合わないことが多いといえます。

また、AIによってコード生成のスピードは上がりますが、生成されたコードを検証し、実運用の中で改善を続ける体制がなければ、作って終わりのアプリが増えるだけになりかねません。

ベータ公開でのフィードバック収集や、失敗を引き継ぐ仕組みとセットで考えることが、内製開発を継続的な取り組みにするために欠かせないと感じています。

外部開発アプリを便利にする

内製開発に向かないと判断した業務領域についても、既製のアプリをそのまま手放すのではなく、外部の会社が開発したアプリをベースとして残しながら、その利便性を高めるという関わり方をしているケースがあります。

具体的には、API連携や、Adobeなど外部アプリ側のプラグイン開発を通じて、自社の業務フローに合わせて手を加えるという方法です。

こちらはすでに社内で取り組みを進めているものの、現時点では外部への発表はしておらず、詳細は今後の状況を見ながらあらためてお伝えする予定です。

内製かゼロか、という二択ではなく、既製アプリに手を加えて使い続けるという選択肢も、開発コストと利便性のバランスを取るうえで有効だと考えています。

セキュリティ担保について

ここまで紹介してきた開発フローで作るアプリは、社内外を問わず日々の業務データを扱うため、開発段階と運用段階の両方でセキュリティを担保する仕組みをあわせて組み込んでいます。

Claude Codeへのセキュリティスキルの組み込みと外部パッケージの脆弱性レビュー

弊社では、Claude Codeにセキュリティスキル（あらかじめ定義したセキュリティ観点でのチェックを行わせる機能）を組み込んだうえで使用しています。

また、コード生成の過程でnpmやpipといったパッケージ管理ツールを通じて外部のパッケージをインストールする場合、Codexによるレビューの際に、そのパッケージに既知の脆弱性（CVE）がないかをあらためて確認するようにしています。

設計・生成を担うAIとは別のAIがレビュー段階でこのチェックを行うことで、便利だからといって脆弱性を抱えた外部パッケージを安易に組み込んでしまうことを防いでいます。

Super Admin権限のログ表示・ログ解析機能による運用後のチェック

さらに、弊社で開発している各アプリには、最上位の管理者権限であるSuper Admin権限に、ログ表示機能とログ解析機能を持たせています。

ログ解析機能では、蓄積されたログをAIがチェックしてリスクの有無を判断し、リスクがあると判断した箇所を自動的に改善する仕組みを組み込んでいます。

これにより、本番リリース後の運用中であっても、サイバーセキュリティ上のリスクを常にチェックし、改善し続けられる体制を作っています。

今後の展開について

弊社では2026年内に、他社との協業により、Q-Toolsの新規事業を基軸とした新しい事業ユニットを立ち上げる予定です。詳細は決まり次第、あらためてお知らせいたします。

今後は、当社の強みであるハード部分（ネットワーク構築やオンプレミスサーバー、AVシステム構築）にアプリケーションによるカスタマイズを加えたサービス開発を進めてまいります。