6つの条件から見るCopilot、Claude、IBM Bob、組織に適した生成AIの選定ポイント

生成AIの導入は業務効率化において必須だ。しかし、知名度や性能で選んで失敗したという例も後を絶たない。本稿では、AI導入の専門家が「Microsoft 365 Copilot」「Claude」「IBM Bob」それぞれの強みを例に挙げ、企業が生成AIを導入する際に、どのように選定候補を絞っていけばよいのかを解説する。

　生成AIどう選べばいいのか迷ってはいないだろうか。文章作成や要約といった基本機能だけを比べても、自社に適した製品は分かりにくい。導入後に「有名な製品を選んだものの、いざ使ってみると我が社には合わない」という事態も起こりがちだ。

　それでは、一体どこを見れば、自社に適した生成AIを決めることができるのか。代表的な生成AIのうち、「Microsoft 365 Copilot」（以下、Copilot）、「Claude」「IBM Bob」の特徴を例に、AIの強みとはどこにあるのか、企業はAIのどこに注目して選定をすればよいのかを、AI導入や技術者育成などを支援するVOSTの毛利克徳氏が解説する。

生成AIを選ぶ前に　整理しておくべき6つの条件

　毛利氏は、製品を比較する前に、以下の条件を整理しておくことを推奨している。

1．資料作成や検索、企画、開発のうち、どの業務に使うのか

2．Microsoft 365など既存環境との統合が必要か

3．個人利用か、部署・全社での利用か

4．機密情報を扱う可能性があるか

5．アカウントや権限、利用状況を誰が管理するのか

6．月額料金の変動をどこまで許容できるか

　そもそも、CopilotとClaude、IBM Bobは同じ生成AIといえども、その役割は大きく違う。Copilotは業務アプリ統合型のアシスタント、Claudeは汎用（はんよう）対話型AI、IBM Bobは開発・システム構築に特化したAIだ。そのため、今回の比較においては、3種を単純に順位付けしているわけではなく、選定ポイントを説明する参考としている。大切なのは、各AIの強みがどこにあるか、どの業務に向いているかという点だ。

　これらの条件を導入前に整理しておけば、機能数や知名度だけで生成AIを選んでしまう失敗を避けやすい。

6つの条件から見る、「Copilot」「Claude」「IBM Bob」の特徴

1．資料作成や検索、企画、開発のうち、どの業務に使うのか

　毛利氏はCopilotについて、「複雑な推論や長文生成の精度は対話に特化したAIに劣る場合があり、開発領域や外部データ分析には向きにくい」と整理した。一方、開発業務では、同じくMicrosoftが提供する「GitHub Copilot」を選べば評価が変わる。「Copilot Studio」なども含めた製品群を一括して“Copilot”と捉えず、対象業務に対応する製品まで確認する必要がある。

　Anthropicが提供するClaudeは、長い文書の読み込み、文脈を踏まえた文章表現、要約、分析などを得意とする汎用型の生成AIだ。Claudeに関しては、複数の利用形態がある。Webアプリ「Claude.ai」のチャット機能は、文章作成や要約、分析などに利用できる。Claude Codeは開発者向けのコーディングエージェントで、「Claude Cowork」は複数工程にまたがる業務を実行する仕組みだ。このほか、「Microsoft Word」「Microsoft Excel」「Microsoft PowerPoint」向けのアドインや、自社システムに組み込むためのAPIも提供されている。

　IBM Bobは、ソフトウェア開発とコーディング支援に特化した生成AIだ。日常的な資料作成や要約ではなく、企画や設計、コーディング、テストまで、開発工程全体を対象にする。また、状況に応じて複数のAIモデルを自動で使い分ける仕組みを備える。資料作成や要約といった一般業務を対象としていないため、それらの領域はほかの生成AIに任せ、IBM Bobは開発領域を担当するという分担になるだろう。

　資料作成や要約については、CopilotとClaudeが候補になる。これらの業務の中でも、定型フォーマットが多く、Microsoft 365上の情報を利用する業務ではCopilotが適している。そして、柔軟な文章表現や企画の壁打ちが必要なら、幅広い情報を整理して対話を続けられるClaudeの評価が高い。

　開発・コーディングではGitHub Copilot、Claude Code、IBM Bobが候補になる。既存の基幹システムの保守や刷新も、これらの開発用AIが対象とする領域だ。

2．Microsoft 365など既存環境との統合が必要か

　Copilotの強みは、「Microsoft Word」「Microsoft Excel」「Microsoft PowerPoint」を代表とする、企業で利用されている「Microsoft 365」の環境に組み込めることだ。一方でClaudeは、Office製品との統合は専用製品であるCopilotほど深くないため、Microsoft 365など既存環境との統合の必要性のみを考えると、Copilotに軍配が上がる。IBM Bobは開発に特化しているため、この軸では判断しにくい。

3．個人利用か、部署・全社での利用か

4．機密情報を扱う可能性があるか

5．アカウントや権限、利用状況を誰が管理するのか

　この3項目は、共に密接に関係しており、どの製品が適しているかという観点よりも、企業がどのように生成AI運用のルールを作るべきかといった、「企業の生成AI運用ルール」という括りで考える必要がある。毛利氏は、企業が生成AIを導入する際は、学習利用や情報漏えい、個人契約での安全性、開発領域での管理体制を確認することが重要だと解説した。

　多くの法人向けプランでは、入力内容をモデル学習に利用しない条件が設けられている。ただし、データの取り扱いは製品や契約プランによって異なるため、導入前の確認は欠かせない。

　一方、個人契約では、有料版であっても「AIモデルの改善に協力する」といった設定が有効になっている場合がある。毛利氏は、従業員の個人契約を会社が把握していない状況では設定の確認と注意喚起が必要だと説明した。そしてそれに関して、会社が整備すべきルールは大きく3つあると指摘した。

　まず、入力してよい情報の線引きだ。顧客の個人情報やID、パスワードなどの認証情報や、社外秘データは入力させないようにする。開発用途ではソースコードやコメント、設定値に機密情報が含まれないかも確認する。次に、誰がどの製品をどれだけ利用しているかを把握すること。そして3つ目として、個人契約ではなく、会社が契約した環境へ集約することを重要とした。

　毛利氏は、契約段階から管理の仕組みが整っていれば、社内審査の土俵に乗せやすくなるとも解説した。企業が探すべきなのは、リスクが存在しない製品ではなく、リスクを理解した上で管理できる構成だ。

　特に差が出るのが、セキュリティ審査の厳しい開発業務であると毛利氏は指摘した。GitHub CopilotやClaudeを導入する場合、法人契約の可否やデータの取り扱い、管理者によるアカウント・権限管理などが自社の要件を満たすかを確認する必要がある。一方、毛利氏は、IBM BobのEnterpriseプランを、統制下で開発する場合の選択肢に挙げ、社内審査の候補に載せやすいと説明した。

6．月額料金の変動をどこまで許容できるか

　導入を検討する生成AIのコストを比較する場合は、利用料金だけでなく予算の立てやすさも確認する必要がある。

　毛利氏は、ClaudeやGitHub Copilotについて、契約プランや利用料によって追加料金が発生する場合があり、月々の費用が予測しにくい点を指摘した。そういった従量課金の場合、使った分だけ支払える一方、毎月の金額が変わると企業としては予算を組みにくい状況になる。

　IBM Bobは、契約プランに応じて「Bobcoin」が割り当てられ、EnterpriseプランではBobcoinパックを追加購入できる。必要量を申請して購入する仕組みによって、社内の承認プロセスに載せやすいと毛利氏は紹介した。また、利用状況とコストを個人やチーム、組織単位で確認する仕組みも用意されているので、予算の消化状況を把握しやすい。

苦労して選んだのに――。生成AIを導入してもなぜ使われないのか

　ここまでは、生成AIの選定軸を基に、各生成AIの強み・弱みを解説した。しかし、生成AIを導入しても現場の従業員が使ってくれないという悩みも多い。そもそも生成AIはなぜ使われないのか。毛利氏は、「企業にとって生成AIの導入前と導入後にそれぞれ『壁』がある」と説明した。

　導入前の壁には、「情報システム部門やDX推進部門のような検討部署がない」「セキュリティや情報漏えいへの不安が強い」「判断する立場の人に知識がなく導入可否を決められない」といった問題がある。生成AIについての社内ルールや管理の仕組みを最初から用意しなければならないことも、担当者が足を止める理由の一つだ。

　導入後には、「使い方を教えないまま従業員に配布する」「期待した回答を一度得られなかっただけで利用をやめる」「社内フォーマットに合わせる修正の手間が上回る」といった問題が壁となる。生成AIをうまく使う人のノウハウが共有されず、個人の中にとどまってしまうケースも少なくない。

　また、経営層と管理部門、現場のそれぞれで、生成AIに対する認識がずれることもある。経営層が「Copilotを導入したので大丈夫」と考えたとしても、情報システム部門では「既存の仕組みで細かく管理できないAIを容易には許可しにくい」と判断することもある。さらに現場では、Copilotを利用できても、本格的なコーディングには不足を感じ、「Claude Code」などを使いたいと考える可能性もある。

　これらの「ずれ」を解消しなければ、導入済みのAIと現場が必要とするAIはずっと一致しないままになりかねない。その「ずれ」が発生してしまう理由は、生成AIの性能の他にも要因があるという。

生成AIを定着させるには　選ぶための明日からのアクション

　生成AIの活用を個人に任せるだけでは、組織には定着しにくい。利用者が毎回プロンプトを書き、試行錯誤する運用では、成果が個人の経験に左右されてしまうことになりかねない。

　毛利氏は、会社や部署単位で生成AIを使う「仕組み」を構築することを勧めた。Copilotなら、Copilot Studioを使い、社内問い合わせや申請処理を任せるエージェントを構築する。Claudeなら、SkillsやCoworkの機能を使って、部門ごとの業務手順を配布する。IBM Bobなら、Skillsを使って開発手順を共有し、変更履歴を含めて管理する。そういった仕組みを整え、共有することが、組織に生成AIが定着するきっかけとなる。

　重要なのは、生成AIの使い方が上手な従業員を増やすことだけではない。うまくいった指示や業務手順を再利用可能な形にし、組織で共有・管理できる基盤に変えることだ。

　毛利氏は、ウェビナーのまとめとして、生成AI選びのために明日から実行できるアクションを挙げた。

　生成AIの導入を進める場合、自社が抱える課題を切り分ける必要がある。現場担当者は、使いたい生成AIがセキュリティや管理体制の条件を満たす可能性を整理し、情報システム部門やDX推進部門に導入を提案する。

　意思決定者や管理者は、従業員が個人契約で生成AIを利用していないかを確認する。その上で利用を一律に止めるだけでなく、会社が正規に使える法人契約の環境を検討し、個人の取り組みを会社の取り組みに変える。

　開発・システム部門では、社内システムの改修や新規開発のうち、統制条件を満たす開発AIで試せる案件を選ぶ。費用のために諦めた小規模な業務システムや、社内で止まっている改修は、最初の対象になり得るだろう。

　今回比較された「Microsoft 365 Copilot」「Claude」「IBM Bob」は、それぞれ生成AIとしての役割が異なることを理解する必要がある。Microsoft 365上での日常業務のサポートや、幅広い文章作成や分析、企画支援、統制された環境での開発業務というように、自社の目的と環境から導入する候補を絞ることが重要だ。

　生成AIができることから考えるのではなく、自社が解決したい業務から逆算することが、導入後に使われる生成AIを選ぶための出発点となる。

イベントレポートアーカイブ

この連載の記事をもっと見る

この記事の著者