林上倫弁護士による寄稿》すごいBD、扱っているのはAI統合力

AI 時代の業務開発は、自分のチームの課題（痛点）に対して全体的に進化させることができる。専業の開発者ではなくても、それは可能だ。このような流れは、どの職種にも備えておくべき前提（心構え）だろう。
（前提：林上倫弁護士の専門記事》AI を分かっている専門家は、AI 時代の勝者になれるのか？ ）
（背景補足：林上倫弁護士の専門記事》蔡阿嘎事件から見る AI 恐怖：怒っているのは AI じゃない、負けるのが怖いだけだ）

この記事の目次

Toggle

• 彼の作ったものは、実はかなり痛点を突いている
• 彼がどうやって AI を入れたかを話す
• でも、Output はもっとできると思う
• 弁護士の観点から見ると、絶対にやるべきことがある：幻覚を抑える
• 彼のこの BD Agent に追加できそうな機能をいくつか
  • 会議記録から自動で契約書の改版を生成
  • 交渉の立場に応じて契約の強弱を調整
  • コンプライアンス審査で、リスクを前で止める
• 最後

あるテクノロジー展示会で、私は大企業の業務開発（BD）担当の責任者に会った。もっと特別だったのは、彼自身が AI を使って、彼らの会社で BD が使う社内システムを自分で作っていたことだ。彼はすごく気前よく、スマホを出して prototype を見せてくれた。私たちはその場で見ながら話し始めた。

私は普段から AI 開発にも関わっているし、もともと弁護士でもあるので、彼の作ったものを見るとどうしてもいくつか余計に考えてしまう。この文章は、あの日の会話を整理して、私が見たこと、そして彼と話して「まだ遊べる」方向性を記録するためのものだ。

彼の作ったものは、実はかなり痛点を突いている

彼はいきなり、とてもリアルな悩みを話してくれた。彼らの BD チームは、外での開発（案件対応）の量が多すぎて、誰ひとり管理者が毎日すべての人の報告を消化できないのだ。管理者が出せる指示はかなり大雑把なものに限られ、店ごと・設置場所（ポイント）ごとに精密な戦術を下すことはできない。しかも BD が案件を投げたあと、互いにバッティング（同業者同士で競合）しやすく、進捗を相互に同期するのも、めちゃくちゃ非効率になる。

そこで彼は App を作った。ログインすると admin 画面が出てくる。そこには多くのレイヤーがあり、最も核心の層で、すべての BD が外で開発しているポイントと成約状況が可視化される。こうするメリットはかなり直接的だ。

1 つ目は、もう口頭で互いに同期しなくてよくなること。各人が次の新しい開発ラウンドを始める前に、一目で他の人が何をしていて、各ポイントがどこまで進んでいるか分かる。2 つ目は、彼自身が管理者の立場に立って、パイプライン全体をそのまま見られること。どの店がどの段階で止まっているかが一目で分かる。

正直、これを見れば「BD をよく分かっている人が作った」ことはすぐ分かる。そのインターフェースのロジックは、エンジニアが空想で作れるものではなく、外で実際に営業を回していたからこそ、このように設計できるのだ。

彼がどうやって AI を入れたか

私は彼に、そもそも AI はどこで使うのか気になって聞いた。彼は「AI をつないで、BD が外で開発するときに使う知識、過去の契約、取引事例を全部整理してデータベース化している」と言った。

彼はすごく実践的な例を挙げた。BD がときどき、チェーンブランドを開発することがあるが、チェーンの交渉（交渉のやり方）は単店舗とはまったく違う。チェーンは規模が大きくて力も強く、利益の交換をするようなことがよくある。でも一般的な BD のトレーニングでは、「相手はどの規模（どのレベル）か、こちらがどんなカード（交渉材料）を出せるのか」をはっきり説明するのが難しい。だから彼はこの部分を AI に答えさせている。この切り口は、かなりうまく掴んでいると思った。

私はさらに、データベースはどうやって作ったのか聞いた。彼は正直に「実は Google Sheet にデプロイして、JS で直接読んでいる」と言った。ただし強調していた点がある。各 BD が何を調べたか、AI が何を返したかは、すべて記録されていて、追跡できるようになっている。さらに彼は、「商家（事業者）の定義」という資料も先に書いていた。AI はまず定義を実行して、新規顧客がどんなタイプかを判断し、その後で取引事例に照合する。

ここで小さな細部があるので特に触れておきたい。私は彼に、「Gemini Flash の無料版には落とし穴がある。トークン上限のせいで、期待した結果にならない可能性がある」と話した。すると彼はそれを前もって考えていて、各質問の“ルート”を先に計画して、固定していた。どんな問題に当たったら、どの分ページだけを読みに行くかを決め打ちしている。これなら読み漏れもしないし、時間もトークンも節約できる。この「無理に詰め込まず、判断してから資料を取る」やり方は、確かに要点を押さえている。

でも、Output はもっとできると思う

ここまでを見て、私は彼に割とストレートにこう言った。「あなたのこれは本当に良いし、あなたたちの使い方にもすごく合っている。でも——AI の“味”はそんなに濃くない。」

私は欠点を探しているわけじゃない。「遊べる余地」があると思ったのだ。彼が今やっていることの本質は、過去の BD にあった“透明でない”“制御できない”“追い回収できない”作業の軌跡を、“透明にして”“見えて”“管制できるようにする”ことだ。この input 面はすでにかなり固い。

でも開発者の観点から見ると、彼は output で詰まっていると思う。彼の成果物はほとんど ChatBox と資料整理に集中している。ChatBox は良いものだけど、彼の output はもっといろいろな場所に出せるはずだ。例えば：

1 つ目は、会社のフォーマットそのままの書類を直接吐き出すこと。MOU やレポートみたいなやつだ。会話を読んだあと、自分で整理させるのではなく。
2 つ目は、異なるインターフェースとフローで、異なるタスクを受け止めること。なんでも同じ対話ボックスに詰め込まない。基盤はどれも LLM でもいいが、状況ごとに違う Agent を設計できる。1 つのタスクには 1 つのフロー、といった形にできる。

弁護士の観点から見ると、絶対にやるべきことがある：幻覚を抑える

この部分は弁護士の立場から彼と話した。彼の作るものは、契約や商業条件に触れる。だから一般の人が考えるよりも、許容できる“誤差”の余地が小さい。

私の習慣は、AI が出力したものに、でっち上げ（憑空の捏造）があってはならないということだ。なので彼には、補足で次の 2 つを入れることを提案した。

1 つ目は、根拠の参照（出典の追跡）を付けること。各出力結果の後ろに citation を付けて、そこをクリックすれば「この一文はどの文書のどの箇所から来たのか」が見られるようにする。これは彼にとって特に重要だ。BD が AI から得た交渉材料を持って現場で戦うなら、出典を後から確認できないのは危険で、検証されていないものを“冒険”として持ち込むことになる。

2 つ目は、temperature を下げること。より正確さが必要で、いい加減に発揮してはいけない場面ほど、モデルのランダム性を抑えるべきだ。これらを組み合わせると、幻覚の入り込む余地はかなり小さくなる。

彼のこの BD Agent に追加できそうな機能をいくつか

彼らの会社には法務と弁護士がいて、契約書は多くがひな形（公版）で、あまり改変しない。そう聞くと、AI の出番はないようにも思える。でも私は逆に、この「見た目はとても堅実（安定）」な場面こそ、工夫の余地があると思う。私は思いつくままにいくつか方向性を彼と話した。

2. 会議記録から自動で契約書の改版を生成

BD が交渉を終えたあとの一番つらいのは、2 時間の会議での議論を正式な条文に落とし込むことだ。AI はこれが得意だ。ひな形を渡して、そのうえで会議記録を丸ごと入れると、結論に沿って新しいバージョンを作り、削除・修正された箇所には追跡修正として印を付けるので、法務はどこが変わったかがすぐ分かる。

3. 交渉の立場に応じて契約の強弱を調整

これは一番面白いと思う。彼のシステム内のロジックとちょうどつながるからだ。ひな形の問題は、毎回の交渉における“力関係の差”を反映できないこと。大企業と話すときは、こちらの立場が弱いので、条項はもう少し柔らかくする。小さな相手と話すときは、こちらが強いので、条項をもう少し硬くできる。どんな契約でも一律に当てはまるわけではなく、各契約はカスタムすべきだ。もし彼の Agent が「相手の規模」に応じて強弱が違うバージョンを自動生成できるなら、彼のシステム内でいう「量級に対応した武器」という発想にも接続できるのではないだろうか？

4. コンプライアンス審査で、リスクを前で遮断する

BD が対外的に出す内容には、しばしばコンプライアンス上のリスクがある。AI は文ごとにチェックしてくれる。どの表現が誇張しすぎか、どの法規に違反しているか、削除すべきか、警告文を付けるべきか。毎日外を飛び回る BD チームにとって、この「事前に止める」能力はかなり実用的だ。

私も彼に一言だけ注意した。「会社として特に残したい条項がいくつかあるなら、それと矛盾しない」。言い回しは変えられるし、口調も調整できるが、実質的にこちらの権利利益を保持することは、技術的にはまったく可能だ。

最後

あの日の話をしていて、私はかなり強く印象に残った。彼は 3 週間かけて、しかもわざわざ自分の予算で、prototype を作り終えるまで会社のリソースを動かさなかった。真の痛点を、使える形に落とし込んだのだ。そして社員はすでに使っており、上司も頷いている。

ここ 2 か月あまり、彼はずっと同じことをやっている——痛点を探し、AI が切り込めるタイミングを探す。私は、AI を使いたい人が持つべき心構えはまさにこれだと思う。「AI がかっこいいから遊んでみる」ではなく、「ここが痛い。AI で止血できないか」を考えること。

結局のところ、いちばん使いやすい AI は、たいてい最も派手なものではなく、業務を一番理解していて、真の痛点に一番近いものだ。こんなに BD が上手い人が、自分の仕事を AI のロジックで考え始めているのを見ると、私は正直、彼が今後どんなものを作っていくのかかなり楽しみにしている。