法人番号を最初から受け取る問い合わせ導線

生成AIに実装させ、人が設計を決めるという分担の一例

権守一城（中小企業診断士／kgsmec合同会社）

要旨

本稿は、筆者の事務所サイトに設けた問い合わせ導線を題材に、コードを書けない支援者が生成AIを用いてどこまで実装でき、何を自ら決めるべきかを検討するものである。導線は、会社名を入力し始めると公的な法人情報から候補が示され、選択すると法人番号と所在地が問い合わせフォームに入る、というものである。実装は生成AIが行い、筆者はコードを書いていない。一方、どの情報を自前で持つか、安全をどう担保するかは人が決めた。本稿は、その判断の内訳を「筆者が指示したこと」と「生成AIの提案を筆者が採用したこと」に分けて示し、減らしたリスクと残るリスクを整理する。結論として、実装の担い手が生成AIに移っても、設計上の判断は人に残り、そこには一定の専門性が要るという仮説を述べる。

キーワード：問い合わせフォーム、法人番号、Gビズインフォ、生成AI、中小企業

1. はじめに

生成AIによって、コードを書いた経験のない者でも、動く仕組みを作れるようになった。筆者もその一人である。では、支援者は何を担うのか。本稿の問いは、コードを書けない支援者は生成AIでどこまで実装でき、何を自分で決めるべきか、である。

題材は、筆者の事務所サイトの問い合わせ導線である。小さな仕組みだが、実装、データの持ち方、安全の担保という三つの論点が一通り含まれている。

2. 問い合わせ導線になぜ工夫が要るか

問い合わせフォームは、見込客が最初に手を動かす場所である。ここでの手間は、そのまま問い合わせをやめる理由になり得る。

受け手の側にも手間がある。会社名は、株式会社の位置、略称、全角と半角などで表記がゆれる。同じ名前の会社も存在する。そのため受け手は、問い合わせを受けるたびに「どの会社か」を調べ直すことになる。

この確認作業は、専任の担当者を置けない企業ほど後回しになりやすい。筆者は、ここが中小企業でまだ手の付いていない改善余地であると考えている。

3. 仕組みの概要

導線は次のように動く。

見込客が会社名を2文字以上入力すると、候補が表示される。
候補から自社を選ぶと、会社名、法人番号、所在地が確定する。
ボタンを押すと、これらが入力済みの状態で問い合わせフォームが開く。
氏名、メールアドレス、相談内容は、フォームの側で入力する。

候補の元になっているのは、経済産業省が運営するGビズインフォである。Gビズインフォは政府が保有する法人データを提供するサイトで、法人番号、法人名、本店所在地は国税庁の法人番号公表サイトを出典としている[1]。掲載情報はAPIを通じて利用でき、利用にあたっては出典の記載が求められる[1][2]。

候補に見つからない場合や、法人でない場合に備えて、会社を選ばずにフォームへ進む経路も用意した。実物は当サイトの問い合わせページで確認できる。実装の手順は別稿にまとめる予定である。

4. 見込客と自社の双方の利点

見込客にとっての利点は、入力が減ることである。所在地を打つ必要がなく、会社名も途中まで入力すれば足りる。

受け手にとっての利点は二つある。第一に、どの会社かを調べ直す作業がなくなる。第二に、法人番号が最初から付いた状態で問い合わせを受け取れる。法人番号は1法人に1つ割り当てられる番号であるため、顧客管理の仕組みに登録する際の鍵として使える。会社名の表記がゆれていても、番号が同じであれば同じ会社として扱える。後から名寄せをする手間を、入口で省くことができる。

つまりこの導線は、見込客への配慮であると同時に、受け手側の業務改善でもある。筆者は、問い合わせフォームを「受け取る箱」ではなく「後工程のデータを整える最初の工程」として設計すべきであると考える。

5. 実装は生成AIが行った

この仕組みのコードは、すべて生成AIが書いた。筆者はコードを書いた経験がなく、今回も書いていない。

筆者が行ったのは、何を作るかを決めること、生成AIの提案を採るか採らないかを決めること、動かして確かめることである。たとえば、入力を打ち間違えた後に候補が出直さない不具合は、筆者が実際に触って見つけ、修正を求めた。

ここから言えるのは、実装の作業は生成AIに任せられたが、何を作るべきかと、できたものが使えるかの判断は任せられなかった、ということである。

6. 人が決めたこと

設計上の判断は、起点によって二つに分けられる。

6.1 筆者が指示したこと

特定のサービスの導入を目的にせず、「会社名を入れ始めたら選べる」ことを要件とした。
サイトの公開操作は生成AIに任せず、筆者が最後に自分の手で行うこととした。
問い合わせフォームに、運営者の情報と個人情報の取り扱いを明記させた。見込客が不安を感じる箇所だと判断したためである。
利用目的の書き方や、保存先についての表現を、実態に合うよう修正させた。

6.2 生成AIの提案を、理由を確かめて採用したこと

氏名、メールアドレス、相談内容は自前の仕組みで受け取らず、問い合わせフォームのサービスに任せる。
外部サービスを利用するための鍵は、コードや会話の中に置かず、所定の保管場所に保存する。

一つ目には経緯がある。筆者は当初、基本的な入力はすべて自前の画面で受け、確認だけをフォームで行う案を出した。入力の流れとしてはそのほうが滑らかに見えたためである。これに対し生成AIは、その方法では個人情報がURLに載ること、自前で受け取る範囲が広がることを挙げ、現在の分け方を勧めた。筆者は理由に納得し、案を取り下げた。

この経緯が示すのは、人も最初から正しい設計を持っているわけではない、ということである。重要なのは、提案の理由を確かめ、採否を決められることである。生成AIは安全な案もそうでない案も出し得る。どちらであるかを見分ける責任は、人の側に残る。

7. 減らしたリスクと残るリスク

7.1 減らしたリスク

自前の仕組みが扱うのは、会社名、法人番号、所在地、相談の種類である。個人情報を自前で受け取らない構成にした。
URLに載るのも上記の情報に限られる。氏名やメールアドレスはURLに載らない。
外部サービスの鍵は、利用者から見える場所に置いていない。

7.2 残るリスク

外部のサービスに依存している。Gビズインフォは、運用上の必要がある場合に予告なく利用を制限することがあり、サービス停止による損害の責任を負わないとしている[3]。止まった場合は、会社を選ばずにフォームへ進む経路だけが残る。
情報の正確性と最新性は保証されていない[2]。移転直後の所在地などは古い可能性がある。
フォームに入った法人番号は、見込客が書き換えられる。受け手は「本人が選んだ値」として扱うべきで、本人確認の代わりにはならない。
候補を返す中継の仕組みは、外部から呼び出せる状態にある。想定外の大量の呼び出しを受けると、この機能は止まり得る。ただし、その場合も会社を選ばずにフォームへ進む経路は残るため、問い合わせ自体は受け取れる。筆者はこの損失を許容できると判断し、追加の制限は設けていない。
生成AIが書いたコードを、専門の技術者が検証したわけではない。

残るリスクを挙げたのは、この仕組みを勧めないためではない。何を引き受けているかを分かったうえで使うためである。

8. この判断に要る専門性

今回、人の判断が要ったのは次の点であった。

どの情報を自前で持ち、どの情報を持たないか。
外部サービスが止まった時に、業務がどうなるか。
見込客が不安を感じるのはどこか。
受け取った情報を、後工程でどう使うか。

これらはコードの知識ではない。業務の流れ、情報の扱い、顧客の受け止め方についての知識である。中小企業が同じことを試みる場合、作る作業を生成AIに任せることはできても、これらを決める人を社内外に置く必要がある、というのが筆者の仮説である。

支援者の側から言えば、コードを書けないことは、実装まで関わらない理由にならなくなった。一方で、何を作るべきかを決め、危ない点を見抜き、動くところまで持っていく役割は、以前より重くなったと考える。

9. 「生成AIへの考え」との対応

筆者は別稿で、生成AI時代の支援を、業務最適化、統制、旗振りの三つで捉えた[4]。本稿の事例は、次のように対応する。

業務最適化：問い合わせの入口で法人番号を受け取り、後工程の確認と名寄せを省いた。
統制：個人情報を自前で持たない、鍵を見える場所に置かない、公開は人が行う、という線を引いた。
旗振り：何を要件とするかを決め、提案の採否を決め、動作を確かめた。

三つの考え方の詳細は、別稿を参照されたい。

10. おわりに

本稿の結論は次の三点である。第一に、コードを書けない支援者でも、生成AIを用いれば動く仕組みまで到達できる。第二に、データの持ち方と安全の担保は人が決めるものであり、生成AIの提案であっても採否の責任は人にある。第三に、その判断には業務と情報の扱いについての専門性が要る。

本稿には限界がある。扱ったのは筆者の事務所という一つの事例であり、問い合わせ件数の変化などの効果は測定していない。生成AIが書いたコードの安全性を第三者が検証したものでもない。本稿の主張は、これらの限界を前提とした仮説である。

参考文献

経済産業省「Gビズインフォとは」
経済産業省「gBizINFO 利用規約」
経済産業省「gBizINFO 情報提供 REST APIポリシー（ver1.01）」
権守一城「生成AIは中小企業支援をどう変えるか」 kgsmec合同会社

Report abuse