「この契約書、収入印紙は必要だっけ？」
法務や総務の担当者でなくとも、契約業務に携わる方なら一度は悩んだことがあるはずです。
特に仕入割戻契約書（リベート契約書）などは件数が多く、判断ミスが許されない業務の一つです。今回は、この課題を解決するために、画像認識AI「Teachable Machine」とAIアプリ開発プラットフォーム「Dify」を組み合わせて、収入印紙の要不要を自動判定するツールの開発に挑戦したプロセスを共有します。
開発の動機：属人化した判断業務からの脱却
私の業務では、システムで作成されたリベート契約書のチェックを行っています。その中で大きな課題となっていたのが「収入印紙の貼付漏れ」です。
達成リベート契約などは印紙税法上の「第7号文書」に該当し、4,000円の収入印紙が必要となるケースがあります。しかし、現場担当者がこのルールを完全に把握するのは難しく、提出された契約書を管理部門が一件ずつ目視で再チェックしているのが現状でした。
「画像を送るだけで、AIが印紙の要不要を即座に判定してくれたら、現場も管理部門も楽になるはず」。そう考え、ノーコードでのツール開発に着手しました。
使用したツール構成
今回はプログラミングの専門知識がなくてもAIモデルが作れるツールを選定しました。
- Teachable Machine：Googleが提供する、画像認識モデルを簡単に作成できるツール。
- VS Code (Visual Studio Code)：コード編集とローカルサーバーでの動作確認に使用。
- GitHub Pages：作成したWebアプリを公開するためのホスティングサービス。
- Dify：作成した判定モデルをチャットボットに組み込むための基盤（今回は連携に挑戦）。
STEP 1：画像認識モデルの作成
＊印紙貼付対象となるのは達成リベート契約なのですが、国税庁で定めている印紙税額の一覧に記載されている文書の中の７号文書にあたり、4,000円の収入印紙の貼付が必要となります。(詳細は下記のリンクから確認ください）
まずはAIに「印紙が必要な契約書」と「不要な契約書」の違いを学習させます。
1. 学習データの準備
過去の契約書PDFを、画像データ（PNG形式）に変換します。pdftoppm などのツールを使用し、契約書を画像化しました。
2. Teachable Machineでの学習
Teachable Machineを開き、「画像プロジェクト」を作成。「収入印紙要」「収入印紙不要」の2つのクラスを作成し、用意した画像をアップロードしてトレーニングを実行します。
学習完了したら、モデルをエクスポート→ダウンロードを選択し、保存します。
驚くほど簡単に精度の高いモデルが完成しました。学習が終わったらモデルを「TensorFlow.js」形式でエクスポートします。
STEP 2：Webアプリとしての実装
エクスポートしたモデルをブラウザ上で動かすため、簡易的なWebページを作成します。
<!-- index.htmlの抜粋 --> <body> <h1>収入印紙チェック</h1> <input type="file" id="input-image" accept="image/*"> <div id="result"></div> <!-- TensorFlow.js と Teachable Machine ライブラリを読み込み --> <script src="https://cdn.jsdelivr.net/npm/@tensorflow/tfjs@latest/dist/tf.min.js"></script> <script src="https://cdn.jsdelivr.net/npm/@teachablemachine/image@latest/dist/teachablemachine-image.min.js"></script> <script src="script.js"></script> </body>VS Codeの拡張機能「Live Server」を使ってローカル環境で動作確認を行った後、スマホからも利用できるようにGitHub Pagesを使ってWeb上に公開しました。これにより、外出先からでもスマホで契約書を撮影し、判定が可能になります。
STEP 3：Difyとの連携への挑戦と課題
ここでさらなる利便性を求め、「Difyのチャットボットから画像を送り、判定結果と印紙に関するQ&Aを同時に行えるようにしたい」と考えました。
Difyのワークフロー機能には「HTTPリクエスト」ブロックがあり、外部のAPIと連携が可能です。しかし、今回作成したWebアプリはフロントエンド（ブラウザ）で完結しており、Difyから叩けるAPIエンドポイントを持っていません。
Difyと連携させるためには、画像を受け取って判定結果を返すバックエンドAPI（PythonやNode.jsなど）を別途構築し、サーバーにデプロイする必要があることが判明しました。今回は時間の制約もあり、Dify上での完全な統合までは至りませんでしたが、「DifyのチャットUIをフロントにして、裏側で専用AIを動かす」というアーキテクチャの構想は固まりました。
現場からのフィードバックと今後の展望
作成したWeb版ツールを実際の業務担当者に見せたところ、非常に鋭いフィードバックをいただきました。
「画像を都度撮影して取り込むのは、業務フローとして少し手間かもしれません。そもそも契約書を作成するシステム入力画面の時点で、AIがチェックしてくれる方が便利ではないでしょうか？」
これは「UX（ユーザー体験）」の核心を突く指摘です。ツールを作ることが目的ではなく、業務をスムーズにすることが目的です。
この意見を受け、現在は「システム画面のスクリーンショット判定」や「入力データそのものをDifyに渡してテキストベースで判定する」など、より実用的なアプローチを検討しています。
まとめ
Dify単体でも強力なAIチャットボットは作れますが、今回のように画像認識モデルや外部ツールと連携させることで、その可能性は無限に広がります。
うまくいかない部分もありましたが、「課題を見つけ、ノーコードツールでプロトタイプを作り、フィードバックを得て改善する」というDXのサイクルを回す貴重な経験となりました。
次回は、バックエンドAPIを整備し、Difyからシームレスに判定できる完全版ツールの開発に再挑戦したいと思います。
【推奨】業務システム化に有効なアイテム
生成AIを学ぶ
システム化のパートナー
VPSサーバの選定
コメント