はじめに
ここまで三つの稿で、AI前提のSIビジネスが工数を前提に成り立たなくなることを、ベンダーの側から論じてきました。第1稿では富士通のValue Pricingを題材に元請けの価格を、第2稿では協力会社を押し流す構造を、第3稿では中小SIerの経営が引き受けるべき決断を扱いました。
しかし、三つの稿が繰り返し指摘したことがあります。舵は、ユーザー企業の側にあるということです。ベンダーがどれほど覚悟を決めても、発注側が「今まで通り」を選び続ければ、ベンダーは人月で受け続けるしかない。そして第2稿で述べたとおり、価値で売る市場が開く時計は、ユーザー企業の変化によってしか進みません。
本稿では、その舵を握る側を正面から論じます。先に、本稿の見立てを述べておきます。
長年のユーザー企業とSIerの関係は、人月を基準とした信頼関係でした。AIは、この基準そのものを無効にします。ユーザーが人月を求め、ベンダーがAIを使って提供すれば、ベンダーの売上は減るしかない。だからベンダーは価値への転換を図る。しかし、ベンダーの相手である情報システム部門は、価値、すなわち事業の成果を評価できる立場にありません。経営も事業部門も、ITは難しいと情報システム部門に任せようとする。つまり、価値を基準にするとは、ユーザー企業の意思決定の仕組みと、それを支える組織の形を、根本から見直すことを意味します。そして、そのことへのユーザー企業側のコンセンサスは、まだできあがっていません。
これは、ユーザー企業とSIerの二者の関係というより、日本のSIビジネスという産業構造が、その買い手の側から成り立たなくなるという話です。順を追って確かめます。
人月という信頼関係
人月は、単なる価格の計算方式ではありません。ユーザー企業とSIerの間に、何十年もかけて築かれた信頼の形式です。この点を正確に見ておかなければ、なぜその関係が変えにくいのかが分かりません。
人月は、投入に対して透明で、成果に対して不透明な価格です。何人が何か月働くかは、誰の目にも見えます。その人数と期間が妥当かどうかは、過去の案件との比較で判断できます。だから発注側は「なぜこの価格なのか」を社内で説明でき、プロジェクトが失敗しても「工数は適正に買った」と言えました。第1稿で述べた「責任の盾」です。
受注側にとっても、人月は合理的でした。要件が途中で変わる、仕様が固まらない、ユーザー側の判断が遅れる。システム開発にはそうした不確実性が常につきまといます。成果で対価を決めれば、その不確実性のリスクはすべてベンダーが負うことになる。人月なら、投入した分は必ず対価になります。ベンダーは、成果を約束する代わりに、人を約束しました。
ただし、この合理性には、もともと前提がありました。工数を高い精度で見積もれる、という前提です。そしてこの前提は、AIが登場するずっと前から、既に崩れていました。
情報システムの黎明期に対象となった業務は、給与計算や会計、受発注といった大規模な事務処理でした。これらは、要件をあらかじめ確定できる業務です。処理の手順は決まっており、例外は少なく、一度作れば長く変わらない。そこで使われたのが、COBOLやPL/Iといった手続き型の言語でした。処理の手順を上から順に、一歩ずつ記述する。要件が決まっていれば、書くべき手順の量もおおよそ決まり、そこから工数を高い精度で見積もることができました。人月が信頼の基準として成立したのは、この時代です。投入と成果の間に、安定した対応関係が実際にあったのです。
しかし、情報システムの適用範囲は広がり、処理の形態は多様になり、作った後も変更し続けることが求められるようになりました。それに応えるために、オブジェクト指向の言語が広く使われるようになります。処理を手順として書くのではなく、部品を組み合わせ、変更に強い構造を作る。この作り方では、要件から手順の量を導くことができません。同じ要件でも、設計の巧拙によって規模も工数も大きく変わる。工数の積算に、もはや合理的な根拠はなくなりました。
それでも、人月は使われ続けました。分かりやすかったからです。根拠を失った後の見積もりは、「過去の似た案件でこれくらいかかった」という経験からの推測になりました。発注側も受注側も、その推測が当たるかどうかを確かめる術を持たず、当たらなかったときは仕様変更や追加工数で辻褄を合わせました。人月という基準の信頼は、この時点ですでに、実質ではなく慣行によって支えられていたのです。
そこにAIが現れました。AIは、残っていた唯一の根拠である「過去の経験」を無意味にします。去年の案件で十人月かかった仕事が、今年は一人月で終わるかもしれない。しかも、AIの技術は急速に進み、来年どうなるかは誰にも分かりません。過去から推測することも、先を見通すこともできない。見積もりの根拠は、完全に失われました。人月という基準の信頼は、AIによって初めて揺らいだのではなく、長く揺らいできたものが、AIによって完全に崩壊したのです。
そして両者は、この約束の上で長い付き合いを重ねました。ユーザーは、自社の業務を知り尽くした「いつもの人」が来てくれることを信頼し、ベンダーは、毎年一定の工数が買われ続けることを信頼しました。要件定義に時間がかかっても、仕様変更が重なっても、人月なら双方が納得できた。業務を知る技術者がベンダー側に蓄積され、ユーザー側の情報システム部門はその技術者との関係を管理する役割になった。多重下請けという供給構造も、この信頼を支える仕組みとして機能しました。
人月とは、ユーザーとベンダーが、リスクと責任をどう分け合うかについて合意した、一つの制度だったのです。それが長く続いたのは、不合理だったからではなく、双方にとって合理的だったからです。この制度の上に、ユーザー企業の予算の組み方、稟議の書き方、情報システム部門の役割、ベンダーの営業の仕方、そのすべてが築かれています。
AIは、人月という基準を無効にする
AIは、この制度の土台を崩します。人月が成り立っていたのは、投入と成果の間に、おおよそ安定した関係があったからです。十人が三か月働けば、これくらいのものができる。その相場があったから、投入を見れば成果を推し量れ、投入で対価を決めても大きくは外れなかった。
AIは、この相場を壊します。同じ成果を、一人が一週間で出せるようになる。しかも、どれだけ速くなるかは、案件の性質と、使う人の力量と、業務の文脈がどれだけ渡っているかで大きく変わる。投入から成果を推し量ることが、もうできません。人月は、価格の基準としての根拠を失います。
ここで、ユーザー企業が人月を求め続けたら何が起きるかを、正確に見ておきます。二つの場合があります。
一つは、ベンダーがAIを正直に使う場合です。工数は減り、請求額は減り、ベンダーの売上は減る。ユーザーは安く買えて満足するかもしれません。しかし、ベンダーは早く仕上げるほど損をする。この契約の下で、ベンダーがAIを本気で使う動機はありません。
もう一つは、ベンダーがAIを使いながら、従来どおりの工数を見積もる場合です。工数は見せかけになり、ユーザーはAIの果実を一切受け取れない。しかも、この場合の方がベンダーにとっては短期的に合理的です。ユーザーが工数で買うと言う限り、ベンダーはこちらへ流れます。
どちらの場合も、ユーザー企業にとって良い結果ではありません。前者ではベンダーが疲弊し、後者ではユーザーが損をする。そして、どちらの場合も、人月を基準とした信頼は崩れます。投入を見ても成果が分からないのですから、「適正な工数」という判断自体ができなくなります。ユーザーは、この見積もりが妥当かどうかを、もう判断できない。判断できないものを、信頼の基準にはできません。
これが、本稿が最も伝えたいことです。AIは、ベンダーの収益モデルを壊すだけではありません。ユーザーとベンダーがお互いを信頼するための基準そのものを、無効にします。ベンダーが価値への転換を図るのは、売上を守るためだけではなく、信頼の基準を別のものに置き換えなければ、関係そのものが続かないからです。そして、新しい基準として残っているのは、成果しかありません。
情報システム部門は、価値／成果を評価できない
では、成果を基準にすればよい。そう言うのは簡単ですが、ここに最大の障害があります。ベンダーが価値を売ろうとしても、それを買う側に、価値を評価できる人がいないのです。
ベンダーの営業が長年向き合ってきた相手は、情報システム部門です。情報システム部門は、システムの要件をまとめ、ベンダーを選び、見積もりを査定し、プロジェクトを管理し、稼働後の運用を担ってきました。これらはすべて、投入を管理する仕事です。工数が適正か、工期が守られているか、品質が基準を満たしているか。情報システム部門は、その判断の専門家として育ってきました。
しかし、このシステムが事業にどれだけの成果をもたらしたか。売上がいくら増えたか、在庫がどれだけ減ったか、顧客の離反がどれだけ抑えられたか。これを判断するのは、情報システム部門の仕事ではありませんでした。成果を定義し、その責任を負うのは、事業部門と経営です。情報システム部門は、事業の成果を評価する立場にありません。そういう役割を与えられてこなかったからです。
ここに、成果で買うことの構造的な困難があります。ベンダーが「このシステムはこれだけの事業成果を生みます。その一部を対価としていただきたい」と提案したとき、情報システム部門は、その成果の見積もりが妥当かどうかを判断できません。判断できるのは事業部門ですが、事業部門は、その商談の場にいません。ベンダーの営業は、価値を評価できない相手に、価値を売ろうとしているのです。
当然、情報システム部門は、自分が判断できる基準に話を戻そうとします。「で、何人月かかるのですか」と。これは保守性でも無理解でもなく、自分に与えられた責任の範囲で話をするという、言ってみれば当たり前の応答です。第3稿で、協力会社の現場がAIに抵抗するのは稼働率という評価への合理的な反応だと述べました。同じことが、ユーザー企業の情報システム部門にも言えます。人月で買い続けるのは、人月でしか責任を果たせない立場に置かれているからです。
だから、ベンダーが価値を売るためには、向き合う相手を変えなければならない。第1稿でそう述べました。しかし、それはベンダーの努力だけではできません。事業部門や経営が、ITの調達の当事者としてその場に出てくるかどうかは、ユーザー企業の側の決めることだからです。
意思決定の仕組みを、根本から見直す
ここで、問題はベンダーとの関係から、ユーザー企業の内側の問題に変わります。
なぜ事業部門と経営は、ITの調達の場にいないのか。ITは難しい、専門的だ、自分たちには分からない。だから情報システム部門に任せる。これが多くのユーザー企業の現実です。事業部門は要望を出し、情報システム部門がそれを要件に変え、ベンダーが作る。完成したシステムが事業に役立ったかどうかは、誰も測らない。測る役割が、どこにもないからです。
この仕組みは、人月という制度と表裏一体です。投入で買うなら、投入を管理できる部門が窓口でよい。成果を問わないのだから、成果に責任を持つ人は要らない。人月が、経営と事業部門がITから離れていることを許してきたのです。
成果で買うとは、この仕組みを根本から変えることです。具体的には、三つの役割を引き直すことになります。
事業部門は、IT投資の買い手になります。 このシステムでどの指標をどれだけ動かすのかを定義し、その達成に責任を負う。ベンダーとの成果の合意も、未達時のリスク分担も、事業部門が当事者として決める。「ITは分からない」という逃げ道は、もうありません。成果を定義できるのは、事業を知る人しかいないからです。
経営は、ITを事業の一部として引き受けます。 年度予算を工数で積み上げるやり方をやめ、成果に連動する支出を認める。稟議の基準を「工数は適正か」から「この成果にこの対価は妥当か」に変える。成果未達のときに誰が責任を負うのかを、事前に決めておく。これらは経営にしかできません。
情報システム部門は、調達の窓口から、基盤とデータとガバナンスの責任者に変わります。 事業部門が成果の買い手になるとき、情報システム部門の役割は消えるのではなく、変わります。各事業部門が個別に動くときに、共通の基盤を整え、データをつなぎ、セキュリティと統制を守る。そして、事業部門が成果を定義するのを、技術の側から支える。情報システム部門が最も強くなるのは、ベンダーと事業部門の間に立つのをやめ、事業部門の側に立ったときです。
これは、ITの調達方法を変える話ではありません。だれが何に責任を持つのかという、企業の意思決定の仕組みと、それを支える組織の形を変える話です。だからこそ、この見直しは、外部から買うときだけでなく、自ら作るときにも同じように必要になります。次節でその点に触れます。そして、これはベンダーのためではなく、ユーザー企業自身がAIの価値を手にするための条件です。成果を定義できない企業は、AIで何ができるかを自分で決められず、誰かが持ってくるものを工数で買うしかなくなるからです。
内製化は不可避である — しかし、情報システム部門への内製化ではない
ここまでは、外部から買うときの話として述べてきました。しかし、役割の再定義が必要な理由は、調達に限りません。ユーザー企業が自ら作るときにも、同じ問題がそのまま現れます。
ユーザー企業の内製化は、避けられないと考えています。理由はコストではなく、俊敏性です。ITはすでに事業の前提であり、その事業環境は不確実で、変化が速く、将来を予測できません。この環境では、事業の変化への対処の速さは、ITを変える速さに等しくなります。外部に要件を書いて渡し、見積もりを取り、稟議を通し、納品を待つ。その時間は、求められる速さに見合いません。そして、内製を諦めていた最大の理由である人材の制約は、その多くをAIが外します。すべてではありませんが、内製化のハードルは確実に下がっています。
しかし、ここに落とし穴があります。内製化の受け皿を、今のままの情報システム部門に置いたら、何が起きるか。情報システム部門が「作る側」になるだけで、成果に責任を持つ主体は、依然として存在しません。事業部門は情報システム部門に要望を出し、情報システム部門が作り、できたものが事業に役立ったかは誰も測らない。ベンダーが情報システム部門に置き換わっただけで、ITが事業から切り離されている構造は変わらないのです。むしろ、外部への発注なら少なくとも金額が稟議に上がりますが、内製なら社員の時間が消えるだけで、投資としての可視性はさらに下がります。情報システム部門への内製化は、業績とITの関係を、より曖昧にする方向に働きます。
だから、内製の主体は事業部門でなければなりません。業務を知る人が、AIを使って作る。自分たちの指標を動かすために、自分たちの手で変えていく。だから成果と責任が一致します。情報システム部門は、前節で述べたとおり、事業部門が作るための共通基盤、データ、セキュリティ、統制を担い、事業部門が作ったものが会社全体として壊れないように支える。内製化とは、情報システム部門が作り手になることではなく、事業部門が作り手になり、情報システム部門がそれを可能にする側に回ることです。
もちろん、事業部門には、AIを使って作る人も、何を作るべきかを決める人も、いまはいません。だから最初は、外部の伴走が要ります。第3稿で述べた、ユーザー企業の事業部門に入って業務とAIをつなぐ伴走者は、まさにこの場所に入ります。ただし、伴走者の役割は、作ることではなく、事業部門が自分で作れるようになるまでを支えることです。これは内製化と外部調達の対立ではなく、内製化のための外部調達という、新しい関係の形です。
そして、ここでも経営の役割が決定的です。事業部門が作り手になるとは、事業部門長がIT投資の責任者になることです。これは事業部門にとって新しい責任であり、進んで引き受ける理由はありません。経営が、ITの投資と成果を各事業部門の事業計画の中に置くと決めなければ、誰も動きません。調達を変えるのも、内製を進めるのも、根は同じです。成果に責任を負う主体を、事業の側に置くことです。
コンセンサスは、まだできていない
ここで、現実を正直に述べておきます。こうした見直しへのコンセンサスは、ユーザー企業の側に、まだ十分にはできあがっていません。
理由はいくつもあります。経営にとって、ITは長年「情シスに任せておけばよいもの」であり、その認識を改める必要性を、まだ切実に感じていません。事業部門にとって、ITの成果に責任を負うことは、新しい責任を引き受けることであり、進んで引き受ける理由がありません。情報システム部門にとって、調達の窓口であることは自分たちの存在理由であり、それを手放すことは誰も望みません。すべての当事者にとって、今の仕組みは、少なくとも今日は楽です。
さらに、制度の壁があります。公共の調達は積算を前提に制度化されており、成果連動の契約を結ぶ仕組みがありません。年度予算は事前に金額を確定させることを求め、成果に応じて変動する支出と相性が悪い。監査や購買の規定は、投入の妥当性を問うように作られていて、成果の妥当性を問う形になっていません。これらは一社の意思では動かせず、動くとしても年単位の時間がかかります。
だから、第2稿で述べたとおり、価値で売買する市場が開く時計は遅い。それはユーザー企業の怠慢ではなく、人月という制度がどれほど深く組み込まれているかの証です。
それでも、ユーザー企業は動くべきだと考えます。理由は二つあります。
一つは、動かないことの損失が、すでに始まっていることです。人月で買い続ける限り、ベンダーは早く仕上げる動機を持たず、AIの果実はベンダーの粗利に吸収されるか、形だけの工数に化ける。どちらもユーザーには届きません。ユーザー企業が変わらないことは、現状維持ではなく、AIがもたらすものを自ら放棄する選択です。
もう一つは、この変化が、ユーザー企業にとって、ITを事業の中に取り戻す機会だからです。日本企業のIT投資が長年、既存システムの維持と運用に費やされ、事業の成長に向かわなかったことは、繰り返し指摘されてきました。その理由の一つは、誰も成果に責任を持たない仕組みが、ITを事業から切り離してきたことにあります。成果で買うとは、その切り離しを終わらせることです。AIは、そのための口実であり、手段でもあります。
コンセンサスがないから動けない、というのは、順序が逆です。コンセンサスは、誰かが動いて成果を見せた後にしか、できあがりません。
どこから始めるか
全社の調達制度を変えることから始めてはいけません。それはコンセンサスができた後にやることであり、コンセンサスを作るのは、一つの案件の成果です。
第2稿で、ユーザー企業の変化は情報システム部門からではなく、事業部門から始まると述べました。AIを使って自分たちで何かを作り始めた事業部門は、工数で買う感覚を最初から持っていません。彼らが求めるのは成果と速さです。そこが入口になります。
やり方は、それほど複雑ではありません。事業部門が、自分たちの業務の中で、成果を数字で定義できる課題を一つ選ぶ。工数ではなく、その成果への寄与を基準に、ベンダーと対価を合意する。情報システム部門は、その案件を審査する側ではなく、事業部門と同じ側に立って、基盤とデータと統制を支える。経営は、その一件に限って、成果連動の支出を認め、未達時の責任の所在を決める。
この一件がうまくいけば、社内に「成果で買うとはこういうことだ」という実例ができます。実例があれば、稟議の書き方が変わり、予算の組み方が変わり、情報システム部門の役割が変わる。コンセンサスは、議論ではなく、実例から生まれます。
そして、この一件には、相手が要ります。成果で売る覚悟を決めたベンダーです。第1稿から第3稿までで述べてきた、元請けの価格転換も、協力会社の作り直しも、この一件の相手方として現れるかどうかにかかっています。ユーザー企業が一件を始め、ベンダーがそれに応える。どちらが先かではなく、同じ案件の両側で、同時に起きなければなりません。
おわりに
人月は、ユーザー企業とSIerが、リスクと責任を分け合うために合意した制度でした。その上に、両者の信頼と、ユーザー企業の意思決定の仕組みと、多重下請けという産業構造が築かれています。
AIは、この制度の基準そのものを無効にします。投入から成果を推し量れなくなる。ユーザーが人月を求め続ければ、ベンダーは正直に使って売上を減らすか、形だけの工数を請求するかしかなく、どちらでも信頼は崩れます。残っている基準は、成果しかありません。
しかし、成果を評価できる人は、ベンダーが向き合ってきた情報システム部門にはいません。経営も事業部門も、ITは難しいと情報システム部門に任せてきた。成果で買うとは、事業部門が買い手になり、経営がITを事業の一部として引き受け、情報システム部門が調達の窓口から基盤と統制の責任者に変わることです。ユーザー企業の意思決定の仕組みと組織の形を、根本から見直すことです。そしてこの見直しは、調達だけでなく、不可避である内製化においても同じです。内製の主体は情報システム部門ではなく事業部門であり、そうでなければ、内製化は業績とITの関係をさらに曖昧にします。
そのコンセンサスは、まだできていません。しかし、コンセンサスは実例からしか生まれません。事業部門の一つの案件から始め、成果で売る覚悟を決めたベンダーと組む。それが、ユーザー企業が自らAIの価値を手にするための、最初の一歩です。
舵は、ユーザー企業にあります。そして、舵を切らないこともまた、一つの選択です。その選択が何を意味するかを、本稿は述べてきました。
参考
- 第1稿「AI前提のSIビジネスは工数では成り立たない——富士通Value Pricingが示すもの」
- 第2稿「『人月で買われる側』はどこへ向かうのか——AI前提のSIが協力会社に迫るもの」
- 第3稿「制約と手段と行き先——下請けSIerは会社を作り直せるか」
新著『【図解】コレ1枚でわかるAI戦略」のご紹介
このたび新著『【図解】コレ1枚でわかるAI戦略 ビジネスパーソンが主導権を握るための「知識と思考」（11月11日 Amazon出荷）』を上梓いたしました。このブログで連載しているAIについての解説は、本書の原稿を基に執筆しています。
本書は、AIプロジェクトでビジネスパーソンが主導権を握るために、何を知り、どう考えるべきかを整理し、豊富な図解とともにわかりやすく解説したものです。初心者向けの手引きでもなければ、エンジニアのための技術書でもありません。その中間に位置する、これまで誰も本格的に向き合ってこなかったテーマに挑んだ1冊と自負しています。
AIに限らず、ITに関わる取り組みは本来、事業に責任を持つビジネスパーソンが主導権を握って進めるべきものです。しかし現実には、技術の難しさを理由に、ITベンダーやSI事業者に任せきりにしてしまうプロジェクトが少なくありません。とりわけAIプロジェクトは、従来のITプロジェクトにはない特異性や技術の急速な進化もあって、「専門家への丸投げ」に陥りがちです。これでは、事業の成果に結びつけることはできません。
そこで本書では、AIプロジェクトの責任を託されたビジネスリーダーが、専門家であるエンジニアと対等に議論し、プロジェクトの主導権を握れるように、AIに関わる技術を数式やプログラム・コードを使わず、概念として理解できるように解説しました。あわせて、AIプロジェクトに特有の法律や規制、プロジェクト管理といった実務実践に欠かせない知識も整理しています。
さらに、AIに関連する数学的知識をまとめた別冊（PDF版）と、本書の全図表（PPTX版・ロイヤリティ・フリー）を、オンラインからダウンロードいただけるようにいたしました。
また本書は、AIプロジェクトをユーザー企業に提案するITベンダーやSIerの皆さんにも、お役に立つはずです。人月ビジネスの前提が崩れつつあるいま、お客様の事業に寄り添う力はこれまでにも増して求められ、AIはそのための「前提」となりました。一方で、AIプロジェクトには従来のITプロジェクトにはない特徴があり、これを理解しないままに取り組めば、お客様をミスリードしかねません。そうならないための知識を得ていただく一助にもなると思います。
今年6月に上梓いたしました『AI実践ドリル30日チャレンジ』（日経BP）が、AIを使って新たなビジネス価値を生み出す「個人のスキル」を磨くための本だとすれば、本書は、企業がビジネスとしてAIプロジェクトに取り組む「組織のスキル」を知るための本です。
既存の業務手順やビジネスモデルを前提に「AIで何ができるか」を考えるのではなく、AIを前提に既存を新しく作り直す、すなわち「AIでどう変わるか」という視点で実務実践に取り組む皆さんを支えたい。2冊に共通するのは、そんな思いです。あわせてご覧いただけますと幸いです。
AIは「使うと便利なもの」から「使うことが前提のもの」へと、その位置づけを変えました。そこに求められるのは、仕事の効率を上げるための「個人のスキル」にとどまらず、業績に貢献する「組織のスキル」です。本書は、その「知識と思考」を提供する1冊です。
AIは使っているものの、働き方が大きく変わった、会社が変わりつつある、そんな実感がなかなか持てない。もし、そんなモヤモヤしたものがあるのなら、ぜひ、本書を手に取ってください。
本書の目次
第1章：AIの現在地〜人間とテクノロジーの役割を再定義する
- テーマ1：そもそも「モデル」とは何か？
- テーマ2：生成AIの根幹「基盤モデル（ファウンデーションモデル）」
- テーマ3：AI、機械学習、ディープラーニング、生成AIの「包含関係」
- テーマ4：ビジネスで必須となる2つのフェーズ：「学習」と「推論」
- コラム1：「AGI」とは何か？
- テーマ5：AI進化の歴史〜「識別型」から「生成型」、そして「自律型」から「AGI」へ
- コラム2：「身体性を持ったAGI」へのロードマップ
- テーマ6：AIの強みと限界
- テーマ7：AI開発で鎬を削る、巨大企業たち
- テーマ8：AIの現在地と、ビジネスにおける「AI」の再定義
- テーマ9：人間との協働モデル〜AIに任せてはいけないこと
- コラム3：「センス」と「利他の精神」が羅針盤
第2章：業務への組み込みと自律型AI（Agentic AI）の実装
- テーマ1：プロンプトエンジニアリングの本質は「指示の構造化」にある
- テーマ2：自社独自の知識をRAGでAIに付与する
- テーマ3：ファインチューニングによりモデルを「専門家化」する
- テーマ4：AIaaSによるスピード導入の定石
- コラム1：タスクを各モデルへ自動で割り振る「AIモデルルーター」
- テーマ5：自律型AI（Agentic AI）の出現と動作原理
- コラム2：4段階のAI×ビジネス活用
- テーマ6：複数エージェントの協働（マルチエージェント）と新標準規格MCP
- テーマ7：AI組み込みによる次世代ユーザー体験（UX）の設計思想
- テーマ8：ノーコード・ローコードAIツールの実務価値とセキュリティガバナンスの限界
第3章：第3章：開発最前線とAIインフラの進化
- テーマ1：Transformer（トランスフォーマー）はなにが革命的だったのか
- テーマ2：リーズニングモデル（推論強化モデル）の衝撃
- テーマ3：推論専用チップの台頭
- テーマ4：小規模言語モデル（SLM）とローカルモデル（AI PC）がもたらす自律分散型インフラ
- テーマ5：バーティカルAI（特化型モデル）の選択基準
- テーマ6：E2Eマルチモーダルモデルによるリアルタイム対話の進化
- テーマ7：説明可能なAI（XAI）の実務上の要求
- テーマ8：現実世界の物理法則を予測・理解する「世界モデル」
- テーマ9：物理空間で自律駆動する「フィジカルAI(ロボティクス)」への接続
第4章：AIプロジェクトの企画と推進
- テーマ1：AIプロジェクトの全体像は、課題から逆算せよ
- テーマ2：自社の課題を発見する「業務機能別ユースケースの見取り図」
- テーマ3：AI推進チームに必要な3つの役割（ビジネス、データ、エンジニアリング）
- テーマ4：全社的なAIリテラシー向上のための「リスキリング戦略」
- テーマ5：死の谷に陥らないためのPoC（概念実証）の進め方
- テーマ6：RFP（提案依頼書）に絶対に盛り込むべきAI特有の要件
- テーマ7：AIプロジェクト特有のコスト構造とROIの正しい見積もり方
- コラム1：生成AIサービスの料金モデル：仕組みと賢い使い分け
- テーマ8：生成AI導入の4大アプローチとベンダー評価軸
- テーマ9：AIの精度を決める「良質なデータ」の条件とデータ・サプライチェーン
- テーマ10：開発手法のベストプラクティス(SaaS利用 vs API連携 vs 独自モデル構築)
- テーマ11：システム開発を再定義する「AI駆動開発」と内製化モデル
- テーマ12：導入を成果に変える「定着マネジメント」〜 死の谷の先にある「定着の谷」
- テーマ13：AIプロジェクトの全体を俯瞰しその進め方を整理する
第5章：リスク回避のためのAIガバナンス
- テーマ1：企業として備えるべき基本のAIルール「社内AI利用ガイドライン」の作り方
- テーマ2：生成AIと著作権〜実務的な対処法
- テーマ3：情報漏洩リスクとセキュリティ対策〜クラウド利用とローカルモデルの使い分け
- テーマ4：AIのバイアスと公平性の問題〜企業のブランドリスクへの対応
- テーマ5：国内外のAI法規制の全体地図〜ルールを「設計要件」として読み解く
- テーマ6：ディープフェイクと偽情報〜「攻撃される側」のリスクへの防衛
- テーマ7：業務の効率化から「事業の再設計」へ〜AIが変えるビジネスモデル
- コラム1：AI主権とは何か
