生成AIはなんてちゃってAIか?エンジニア視点の生成AI > 

生成AIによる業務システムのコーディングの可能性

生成AIによる業務システムのコーディングの可能性【2026年1月】

生成AIによる業務システムのコーディングの可能性 メニュー


生成AIによる業務システムのコーディングの可能性

100%要件を満たすような業務(コーディング)には向いていない

人がコーディングした場合「設計書の機能を満たすソースコード」を記述する。

生成AIによるコーディングも、人と比較し多少の記述に違いがあっても、「設計書の機能を満たすソースコード」という点は100%実現する必要がある。

生成AIは「大規模データからの確率による最適解」を出力しているので、100%要件を満たすような業務(コーディング)には向いていない。

※生成AIの推論モデル(埋め込みベクトル、Self-Attention、統計的確率分布など)は一定量のハルシネーションが発生する事を前提にしてる。

生成AIのよるコーディングはUI(画面回り)だけ

社内で使う業務システムのUI(画面周り)は、多少の問題があっても大問題にはならない。

UI(画面周り)の要件は比較的単純で「入力→入力時のチェック」「出力」だけだ。UIは生成AIによるコーディングの可能性が考えられる(業務要件が関係するような入力チェックは複雑なので除く)。

前述のとおり、生成AIは推論モデルでありバグは混入するので、人によるコーディング以上の試験が必要になる。

ビジネスロジックを伴う機能では利用できない

GPT4は、トランザクションが発生する処理(データ通信、データベース関連)のコーディングに利用できる可能性はゼロと言っていい。

銀行の勘定系システムを例に説明する。

自行内の処理は全銀ネットワークや他行と通信は発生しない。

生成AIを利用できるのは製造工程の1割に満たない

勘定系システムにおけるUI(画面周り)は、製造工程全体の工数の1割程度だ。

生成AIを用いて効率化されるのは、この製造工程の1割に満たない工程なので、あえて生成AIという全く別の製造方法を用いるメリットはない。

生成AIを使う事で、試験の方法、バグの排除、工程管理などを含む品質管理を分けて考える必要がでる。

結果的にプロジェクト管理が複雑になり、最も重要な、品質、予算、納期に影響を与える可能性があり、リスクに対して得られるリターンを考えると生成AIを利用するメリットは現状では全くない。

UI(画面周り)は製造工程全体の工数の1割程度
  1. UI(画面周り)は、製造工程全体の工数の1割程度。

  2. 生成AIを使う事で、試験の方法、バグの排除、工程管理などを含む品質管理を分けて考える必要で、プロジェクト管理が複雑になる。

ハルシネーションが限りなくゼロに近づいても、生成AIは人間書いた設計書を理解できない

ハルシネーションが限りなくゼロに近づいても、生成AIは人が書いた表記ゆれのある設計書を理解できる事には繋がらない。

生成AI側に寄せて最適化された設計書を書くと、設計書が膨大な量になってしまい現実的ではない。

UI(画面周り)の要件は比較的単純で「入力→入力時のチェック」「出力」だけだ。

業務要件が関係するような入力チェックは、やはり生成AIに寄せて設計書を作ると大変なので現実的ではない。UIに使えると言っても部分的でしかない。

人が書いた設計は設計書は、表記ゆれがあり、また不完全な事も多い。

設計書段階でのミス・モレを、人はどこかの工程で気付く事ができるが、生成AIにコーディングを丸投げしてしまうと、生成AIはこの要件は曖昧だ、場合によっては機能バグなのではないか?といった事には気づけない。

人も最初は気付かない事が多いが、コーディングしている最中に気づくなど、どこかで気付く。

これは知識、経験と能力による気づきだが、その結果SEに「ここは厳密にはどういう処理ですか?」のような質問が起こり、最終的には問題を解決する。

生成AIは学習データから確率的に最も適切であろう回答を選択をしてくるので、この気付きのようなものを生成AIが実装できるかがポイントになる。現状では気付くという反応は生成AIにはないように見える。

「埋め込みベクトル」「Self-Attention」「統計的確率分布」などが生成AIのコアアーキテクチャで、これらのモデルで果たして気付きの実装がされているか?というと懐疑的だ。

生成AIは人間書いた設計書を理解できない

また気付きが実装されても、その気づきから問題のポイントをブレークダウンしていく厳密な会話を、推論モデルで実装できるのか?これは可能性はあると思うが、現在の技術の延長線上ではなく、もう1つ2つエッセンスが必要だと考えている。

生成AIは設計書の問題に気付く事ができない
  1. 人は設計書の問題に気付く事ができるでの問題は解決される。

  2. 生成AIに気付きはなく、問題を見つける事ができない。



実業務での生成AIの利用

実業務では業務ルールの変更が多発し生成AIは使えない

業務で「ミス・モレ」は許されない。業務システムでは「ミス・モレ」が可能な限り発生しないように設計する。

生成AIの推論モデルは、その名のとおり「確率的な推論」であるため、「ミス・モレ」が発生することが前提条件になりる。「ミス・モレ」を許さない業務とは完全にコンフリクトしている。

業務で生成AIを利用する場合、ルールベースの業務を学習させる必要があるが、ここで問題が生じる。

生成AIの学習には多大な時間とコストがかかる。簡単にルールベースの仕組みを組み込めるわけではない。

生成AIが活躍できる分野

生成AIが面白いのは、一般的な会話や、ちょっとした専門性のある会話まで、曖昧性を理解しているように思えてしまうところだ。

生成AIが行っているのは、学習データを元に「埋め込みベクトル」「Self-Attention」「統計的確率分布」などの理論(ロジック)をぶん回しているだけだが、それが結構、的を得ているように感じるし、ひょっとしたら本当に的を得た回答になってる可能性もある。

「人間の思考プロセス」と「生成AIの推論プロセス」は似ている。明らかな違いはハードだ。人は「脳細胞(神経回路)」、生成AIは「CPU・GPU・メモリ」で処理する。

ただし、脳の処理は全く解明されていない。
AI)「大量のデータ」を元に「確率計算」
人)「記憶」と「経験」から「〇〇」で最適な応答を選んでいる。○○は現状では解明されていない。

人がどのように最適な回答を導き出しているかは?全くわかっておらず、場合によっては数百年経っても解明されない可能性もある。

もう1つ、生成AIが決定的な弱点が、思考錯誤がデキナイことだ。

生成AIの学習データの作成は、数カ月かかるので頻繁には出来ない。ユーザー単位での一時ストレージとして長期メモリは持っているが、長期メモリは学習データには反映されない。

つまり、コンソールで試行錯誤が発生しても、学習データにはフィードバックされないので進歩しない。学習させる内容を厳選しないと生成AIが使い物にならなくなるので、試行錯誤と学習データはコンフリクトする関係にある。

この問題は「何を学ぶか?」短い間隔で判断しAIが取捨選択できるようになる必要がある。

また、AIは自分で自分のソースコードを改変できない(安全上あってはならない)。

何を学ぶか?もAIに判断させると危険である可能性がある。学ぶ内容の選択は、人が主導権持ち、当面手放す事ができない。

私も生成AIにはかなり期待している。特に日本は子供から老人まで介護者(子供は保育)が圧倒的に足りず、近い将来、汎用ロボットによる介護が実現されだろうが、心までは介護できない。

汎用ロボットにAIの搭載は必然だが、介護のような人に寄り添う分野でAIは社会的になくてはならいない解決策になると考えている。

おすすめ記事

レキシコン レキシコン

レキシコンは語彙の集合(辞書的な知識)で「コンピューターにおけるレキシコン」と「言語学におけるレキシコン」「哲学・認知科学におけるレキシコン」では意味が変わってくる。

生成AIは膨大なレキシコンを学習させているので、レキシコンの持つ単語同士の意味や関連性を理解している・・・  続きを見る 

生成AIで使用される技術 生成AIで使用される技術

統計的な意味理解において、埋め込みベクトル(Word Embeddings) は最も重要な要素の一つだが、それだけでは不十分で、他にもいくつかの要素が影響する。

生成AIは「埋め込みベクトル(Word Embeddings)」「Self-Attention, Transformer」「統計的言語モデル(統計的確率分布)」などを組み合わせることで、より深い意味理解が可能になっている・・・  続きを見る 

生成AIのルールベースのアプローチ 生成AIのルールベースのアプローチ

生成AIは、明確な誤り(例えば、型不一致や文法エラー)については、ルールベースのアプローチが適用される。

「答えがA = Bしか存在しない」といった、単一の正解しかない(正解が1つしか存在しない)場合も、基本的にはルールベースのアプローチが適用される・・・  続きを見る 

生成AIによる業務システムのコーディングの可能性 生成AIによる業務システムのコーディングの可能性

生成AIは「大規模データからの確率による最適解」を出力しているので、100%要件を満たすような業務(コーディング)には向いていない・・・  続きを見る 

Copyright (C) 2017~2026年 nurikaeya.jp All Rights Reserved. Update 2026年1月17日
運営者情報 ご質問はこちらへお願いします info@c-show.jp