AI開発ツールで電子契約システムを作って壁にぶつかった話

はじめに

私はAI開発ツールを使って、電子契約システムを開発しています。ノーコード・ローコードの範囲を超えて、認証、PDF生成、メール送信、監査ログまで備えた本番プロダクトです。

開発は順調に進んでいたのですが、PDF生成でどうしても解決できない問題にぶつかりました。

今回は、その問題をClaude Opus 4.6（Anthropicの最上位AIモデル）と一緒に解決した過程をそのまま共有します。「AIで開発するってこういうことか」というリアルな雰囲気が伝われば嬉しいです。

ぶつかった壁：Edge FunctionのCPU制限

電子契約システムでは、契約が締結されるとPDFを自動生成します。契約書PDFと締結証明書PDFの2種類です。

この処理をSupabaseのEdge Function（サーバーレス関数）で実行していたのですが、日本語フォント（約4MB）の読み込み+PDF描画でCPU制限を超過してしまい、処理がタイムアウトするようになりました。

日本語のPDF生成は英語に比べてかなり重い処理です。漢字のグリフ（字形データ）が膨大なので、フォント読み込みだけでサーバーのリソースを食い尽くしてしまいます。

AI開発ツールの提案：「ブラウザ側でPDF作りましょう」

AI開発ツールに相談すると、「PDFの生成処理をブラウザ側に移しましょう」という提案が返ってきました。

つまり：

変更前： ブラウザ → Edge Function（PDF生成+保存+メール送信）
変更後： ブラウザ（PDF生成）→ Edge Function（保存+メール送信のみ）

技術的には筋が通っています。ブラウザならCPU制限がないし、pdf-libというライブラリも既にインストール済み。

でも、ここで「本当にこれでいいのか？」と立ち止まりました。

Claude Opusに相談：「セキュリティ大丈夫？」

AI開発ツールの提案をClaude Opusに見せて意見を聞きました。返ってきた答えは：

電子契約書のPDFをクライアント側で生成する設計は、契約の信頼性に関わります。

具体的な指摘は3つ：

改ざんリスク： ブラウザのDevToolsでPDF生成ロジックを改ざんし、契約内容と異なるPDFを作れる
ハッシュのすり抜け： ドキュメントハッシュもクライアントから送られるので、改ざんPDFに対応するハッシュを送ればサーバー側チェックをすり抜けられる
認証の弱さ： verify_jwt = false + ステータスチェックのみという保護では不十分

これはAI開発ツール単体では出てこない視点でした。

「じゃあどうする？」— 3つの選択肢

Claude Opusは代替案も提示してくれました。

案A：フォントサブセット化（サーバーに残す） 日本語フォントを必要な文字だけに絞り込んで軽量化。4MB→数百KBになればEdge Functionで処理できる可能性がある。

案B：非同期処理（外部サーバー） PDF生成をリアルタイムでやらず、別サーバーで非同期処理。確実だが運用が複雑。

案C：ブラウザ側生成 + サーバー側セキュリティ補強 AI開発ツールの提案をベースに、サーバー側でハッシュ再計算や監査ログを追加。

まずフォントサブセット化を試す → 新たな問題

案Aが最もシンプルなので、まずこれを試しました。

実は以前にもサブセット化を試みていたのですが、証明書PDFで文字化けが発生していました。

Claude Opusに相談すると、原因は明快でした：

人名に使われるJIS第二水準の漢字（渡邊、齋藤、髙橋など）がサブセットに含まれていなかった

契約書のテンプレート文面はJIS第一水準で足りますが、証明書には署名者の氏名が入ります。「渡邊」の「邊」はJIS第二水準、「髙橋」の「髙」はIBM拡張文字。これらが漏れていたのです。

Claude Opusに「JIS第一+第二+人名用漢字+IBM拡張」のサブセットフォントを生成してもらいました。結果は約3.4MB。元の4MBから劇的な削減にはなりませんでした。

方針転換：案Cで行く

フォントサブセット化だけではCPU問題の根本解決にならないと判断し、**案C（ブラウザ側生成+サーバー側セキュリティ補強）**で進めることにしました。

ここでのポイントは、AI開発ツールの元案からの4つのセキュリティ追加です：

ハッシュはサーバー側で再計算（クライアントのハッシュは受け取らない）
PDF上書き防止（保存済みなら拒否）
監査ログ（IP、User-Agent、タイムスタンプをDB記録）
冪等性（べきとうせい）の確保（同じ操作を何回やっても安全にする）

4つ目の「冪等性」(べきとうせい)は聞き慣れない言葉かもしれません。「同じ操作を何回やっても結果が同じになる」という性質のことです。エレベーターの「5階」ボタンを1回押しても3回押しても、行き先は5階。これが冪等。逆にECサイトの「購入する」ボタンを3回押したら3回購入されてしまうなら、それは冪等ではありません。今回のケースでは、PDF保存中にネットワークエラーが起きて「成功したかわからない」時、ユーザーが再試行ボタンを押すことを想定しています。既にPDFが保存済みなら「既に存在するのでOK」と成功を返す。何回押してもPDFは1つだけ、結果は常に同じ。これが冪等性の確保です。

やり取りの中で生まれた改善

ここからが面白いところで、AI開発ツールとの実装のやり取りの中でいくつもの改善が生まれました。

「2つまとめて送るから6MB超えそう」→「1つずつ送ればいい」

当初の設計では契約書PDFと証明書PDFを1回のリクエストで送る予定でした。でもBase64エンコードで1.33倍に膨張するので、Edge Functionの6MBリクエスト上限に引っかかる可能性がありました。

解決策は単純で、1つずつ送ればいい。 メールも1通ずつ分けて送る方がユーザーにとっても分かりやすい。

「ハッシュ欄が空欄だと顧客が不安になる」→ セクション丸ごと削除

ブラウザでPDFを生成する時点ではハッシュ値が未確定なので、契約書PDFのハッシュ表示欄を空にする案がありました。でも「文書ハッシュ (SHA-256):（空欄）」と表示されたら、受け取った顧客は「壊れてる？」と不安になります。

そもそも契約書のハッシュは証明書PDF側で表示される（「この契約書のハッシュは〇〇です」）ので、契約書PDF自身には不要。セクション丸ごと削除しました。

AI開発ツールが `upsert: true` のフォールバックを入れていた → 必須で削除

上書き防止のために upsert: false で保存する設計なのに、エラー時に upsert: true で再試行するフォールバックがAI開発ツールの実装に含まれていました。AI開発ツールは「任意の改善」と言っていましたが、これは必須の修正です。レースコンディションで悪意あるリクエストが上書きできるセキュリティホールになるからです。

テストで発覚：旧フローが動いていた

実装完了後のテストで、エラーが発生しました。コンソールを見ると 401 (Unauthorized)。

AI開発ツールの分析は「認証チェックを外しましょう」でした。

しかしClaude Opusの指摘は違いました：

そもそも新フローが動いていない。旧フローにフォールバックしている。

原因を追うと、「既に承認済みだがPDF未生成の契約に再アクセスした場合」に、新フローに必要なデータが渡されないパスがあったのです。

AI開発ツールは「旧フローの延命（認証チェック削除）」を提案しましたが、正しい対応は「新フロー内でデータ取得を補完する」ことでした。旧フローを残すと、どちらが実行されたか分かりづらくなるからです。

これはAI実装で最も危険なパターンの1つです。 「動かないから応急処置」を繰り返すと、旧コードと新コードが混在してカオスになる。

三者体制の効果

今回の開発で確立したのは、AI開発ツール（実装者）+ Claude Opus（設計アドバイザー）+ 自分（最終判断） という三者体制です。

役割	担当	得意なこと
実装	AI開発ツール	コード生成、UI構築、DB設計
設計レビュー	Claude Opus	セキュリティ分析、アーキテクチャ判断、リスク指摘
最終判断	自分	ビジネス要件との整合、UX判断、優先順位決定

AI開発ツールは優秀なコーダーですが設計者ではありません。言われたことは正確にやりますが、「このケースどうなる？」を先回りして考えるのは苦手です。

Claude Opusは設計の穴を見つけるのが得意ですが、実際にコードを書いてAI開発ツールに適用するのは人間が仲介する必要があります。

そして最終的に「どの案で行くか」「顧客から見てどうか」を判断するのは人間の仕事です。

まとめ：AIで本番プロダクトを作るとはどういうことか

AIコーディングツールの進化で「誰でもアプリが作れる」と言われます。プロトタイプレベルならその通りです。

しかし本番プロダクト、特にセキュリティや法的要件が絡むシステムでは、AIが出した答えをそのまま採用するのは危険です。今回のケースでも：

AI開発ツールの提案をそのまま採用していたら、改ざん可能な電子契約システムになっていた
upsert: true のフォールバックを「任意の改善」として放置していたら、セキュリティホールが残っていた
旧フローの応急処置を繰り返していたら、メンテナンス不能なコードベースになっていた

AIは最高の実装パートナーですが、設計とレビューは人間がやるべきです。

それは「AIが信用できない」という話ではなく、AIをどう使えば最高の結果が出るかを知っている人間が必要という話です。

これが「バイブコーディング」で本番プロダクトを作るということであり、私がBANSOU CTO™（伴走CTO）として提供している価値でもあります。

この記事で扱った電子契約システムはIIWAYO.TECHで開発しています。AI開発ツールを使ったシステム開発やBANSOU CTO™サービスについてはお気軽にお問い合わせください。

次に読むおすすめ

「トークンをケチるな。トークンを燃やせ。—AI開発を習得したい人に伝えたいこと」
「オフショア開発はAI時代に通用するのか—構造的な問題と、広がる格差」
「なぜシステム開発会社はAI開発に移行できないのか—月50万円と400時間の壁」