An embedded project arrived with polished AI-written code and fancy docs, yet failed on real hardware. Learn red flags and acceptance questions to demand proof of testing.
相模原市で IoT 設計を受託しているファームロジックスです。
信じられない方も多いと思いますが、最近、こんなお話を聞くようになりました。
AI が書いたソフトウェアに、AI が書いたドキュメントを付けて納品してきた!?
私が拝見した「あるソフトウェアコード」も、見た目は非常にしっかりした作りで、インデンテーションも、変数名の付け方も、エラー処理も一見すると見事に設計されています。ドキュメントだって、「納品時に普通、こんな凝った実装仕様書なんて作らないよね」というような、チャートやアイコンが満載の素晴らしい作りです。誰だって、そんな納品物を見たら、これは間違いないよね、技術のある設計者さんなんだろうね、って信じてしまうでしょう。
私のように長年、組込ソフトウェア設計に携わっている人間でも感心してしまうのですから、一般の管理者さんや、受入れ担当者さんが、それを AI による作品だと気づかないのは無理もないと思います。
企業の管理者さん、設計受入れ担当者さんは、これからの時代、何に注意したら良いのでしょうか。その点は、このブログの最後にまとめさせていただきます。お急ぎの方は、最後だけお読み頂いて結構です。
AI が仕事を奪う時代?
少し違う話をしましょう。
以前から皆様も、ネット上に溢れる「新商品の紹介」、「飲食店のレビュー」、「観光案内」などの記事を安価に請け負う業態が広がっていることをお聞きではないかと思います。「何文字で 100円」というような、非常に過酷なお仕事だそうです。最近は仕事の単価が低すぎるため、そのような原稿を AI に書かせているという話があります。
それに加えて、最近はイラストや音楽を AI が作ってしまうようになり、イラストレーターさんや作曲者さん、海外では俳優さんなども AI に仕事を奪われている、などというニュースを聞くようになりました。
私は、まだまだ自分の業界からは遠い世界の話だと思っていたのですが、どうも、考えが甘かったようなのです。
お客さんの不審な目
あるお客さんが、私のところにそんなソフトウェアとドキュメントを持ち込んできました。
お客さん: いや、もうコードはできているんですよ。ドキュメントだってバッチリなんだ。ただ、動作確認をしてくれる技術者がいなくてねえ…。ファームロジックスさんにお願いできないかな、と思ってね。
動作確認だけだったらお安い御用です。キレイに書けたコードですねぇ。1週間もあれば動作確認できるんじゃないでしょうか。
とんでもない話です!
実際にボード（電子回路基板）に電源を入れて、コードを流してみますが、まったく動きません。きっと、私のビルド（コンパイル作業）が間違っているのだろう、あるいは、何か動作環境に、設計者さんと私の間で違うところがあるのだろう。問い合わせをしてみなくては…。
しかし、よくよく見ていくと、回路上で電源を供給しなくてはいけない部品に電源が供給されていません。トランジスタのドライブ論理を忘れているのでしょうか。また、あるモジュールの I2C アクセスは初めからエラーで止まっていたりします。そんな問題がいくつも見つかります。どうも、動作確認をした形跡がほとんどないのです。
30分後に私は考えました。
このソフトウェア設計者は、実機でソフトウェアを走らせたことがないだけでなく、おそらく、回路図だってちゃんと見てないに違いない。ただ、机上で、もっともらしいコードを書いただけだ。
しかし私の経験から言って、組込設計者というのは、机上だけで延々とコードを書き連ねるということは現実的に、心理的に、不可能なのです。コードを少しずつ実機で動かしてみて、ようやく設計がぼちぼちと進んでいく、というのが本当なのです。
1時間後に私は結論（確信）に達しました。
これは人間が書いたコードじゃない。AI に顧客の要求を渡せば、なんとなく仕様を満たしたような、コンパイルが通るくらいの、長々としたプログラムコードを書いてくれるのに違いない。
さらに不審な気持ちでドキュメント（パワーポイント）をよく見てみると、そこには PptxGenJS というツールで生成されたというシグネチャが残ったままでした。世の中に、プレゼンを作るのに JavaScript で書く人は多くないでしょう。実際にネットで調べてみると、AI にプレゼン資料を作らせるという記事がいくつも見つかります。AI が裏で PptxGenJS を動かしているのではないでしょうか。
苛立ちもありましたが、AI にここまでできるんだ、という感心すら覚えました。
しかし、問題はそこでは終わらなかったのです。私はお客さんの反感を買わないように注意しながら報告したのですが、お客さんは、私よりもその成果物のほうを信じてしまっているように感じられます。ネット会議の遠くにお客さんの白い目が見えるようです。
横山さん、そんなことないでしょう。こんな綺麗に書けたコードですよ。この設計者さんは、本当に技術力のある方なんですよ。
「AI が仕事を奪う」という本当の意味
去年 Harvard Business Review で、こんな記事（AI-Generated “Workslop” Is Destroying Productivity）が話題になりました。直訳すれば、
AI が生み出す「Workslop」が生産性を破壊している
という話です。
Workslop とはなんでしょう? このタイトルを意訳すると、「AI による量産型の質の低いアウトプットが、
意思決定の質と業務効率を同時に悪化させている」とでもなるでしょうか。
私は不安な気持ちになってきました。確かに、本当に AI は技術者の仕事を奪うかもしれません。しかし、それは AI が高度な技術を持って技術者を駆逐する、というだけの意味ではないようです。それより深刻なのは、もっともらしい、しかし実態は「張りぼて」のような成果物が、経営者や管理者を混乱させ、そのような人々の生産性を「破壊」することが、「AI が仕事を奪う」という本当の意味なのではないでしょうか。
管理者さん、受入れ担当者さんのためのチェックリスト
最近、企業の人事担当者と学生の間で、AI 競争が起きているそうです。学生さんは AI を駆使することでたくさんの企業に応募書類を書くことができるようになり、その一方で、企業の人事担当者さんは AI を使って応募書類を「ふるい分け」する。つまり、いたちごっこです。
企業の受け入れ担当者さんも、設計成果物を見るときには、それが本当に人間によって作られたものなのか、納品者さんに、人間でないと答えられないような質問をしてみることをお勧めします。
- 設計のこの部分ですけれど、どういう指針（方針）で設計なさいましたか?
- 同じような設計で、以前にご苦心なさった経験はありますか?
- 要求仕様や設計のインプットに不備や矛盾が多かったのではないですか? どのように対応なさいましたか?
- （組込設計であれば）ハードウェアの設計者さんとは、どのような情報交換をなさいましたか?
- この納品物ですが、どこまで動作確認できていますか? まだ解決できていない残存問題のリストはありますか?
もう一つ、知っておいていただくと良いポイントがあります。コンピュータソフトウェアの設計には多くの領域がありますが、その一つである「組込設計」の領域には、一つ大きな特徴があります。それは、
組込設計は、クラウド上だけで設計を完結できない
ということです。組込設計というのは、常に、実態のあるハードウェアで動かさないと最終的な動作確認ができません。最近はシミュレーション技術が進歩し、組込設計でも多くの部分を仮想的に検証できるようになりましたが、最終的な動作確認だけは、どうしても、電気で動く実際のハードウェア、あるいはアクチュエータやメカニズムが必要です。
AI に実際のハードウェアをアクセスさせるには、高度な統合技術が必要で、コストもかかるものなのです。（私はいま、ターミネーターという映画を思い出してしまいました。）
ここまで読んで頂いた皆様は、この記事はファームロジックスの我田引水、利益誘導ではないかとお考えの方も多いかと思いますが、組込ソフトウェアのは受入れでお困りの際は、ぜひファームロジックスに御相談ください!
お問い合わせはお気軽に!