生成AIの進化により人間の仕事がAIに置き換えられる事例が増えています。大手テクノロジー企業のMicrosoftでさえ、ソフトウェア製品のコードの30％がAIにより記述されていることを明かしています。しかし、すべてがいい方向に作用しているわけではないようで、2025年春に実施されたMETRの実験により、AIコーディングツールは人間の生産性を低下させていることが明らかになりました。
AIコーディングツールは生産性を19％も低下させているという調査結果、AI出力の評価・手直し・再出力などで無駄な時間が大量発生か - GIGAZINE
調査では開発者へのインタビューと画面録画を分析することで、「なぜAIを使うと生産性が低下するのか？」の原因をいくつか特定することに成功しています。
AIコーディングツールは生産性を19％も低下させているという調査結果、AI出力の評価・手直し・再出力などで無駄な時間が大量発生か - GIGAZINE
最大の問題は、AIツールによって生成されたコードが一般的にオープンソースプロジェクトの高い基準を満たしていないためです。開発者はAIによる出力をレビューするのに多くの時間を費やすこととなり、AIに追加で指示を出したり、コード生成を待ったり、致命的欠陥がある場合は出力を破棄したり、再びAIに指示を出したりと、同じ作業を何度も繰り返さなければならなくなるケースがありました。
AIコーディングツールは生産性を19％も低下させているという調査結果、AI出力の評価・手直し・再出力などで無駄な時間が大量発生か - GIGAZINE
実際、Cursorが出力したコードのうち、開発者が使用したのは39％だけだったと報告されています。なお、この39％のコードもそのまま使用されているわけではなく、開発者によるレビューや手直しが行われています。
AIコーディングツールは生産性を19％も低下させているという調査結果、AI出力の評価・手直し・再出力などで無駄な時間が大量発生か - GIGAZINE
⇧ まぁ、当然の結果と思うのだが。
そもそも、不確実性の高い「ソフトウェア開発」のタスクを「生産性」に換算できない気がするんだが...
「コーディング」以外にも様々なタスクが存在するのに、「コーディング」に対してだけ「生産性」を語り出すのは意味が無い気もする...
実際に「コーディング」の工数の増減に着目するならば、工数を削減できる要因としては、実現方法に必要な情報を知っているかどうかだけでしか無いので、引き出しの数が多いかどうかが重要な気はするのだけど、その部分については「生産性」として評価できない気がするので、数値化が不可能な気がしている...
方式を決めるための技術調査に一番時間がかかる気がするので。
話を「AI」の弊害についてに戻すと、最終的に「意思決定」するのは人間がせざるを得ないはずなので（余程クレイジーなマインドの持ち主でない限り「AI」の回答を全面的に採用するということはあり得ないと思うが）、
- 幻覚（ハルシネーション）が発生している箇所
- 幻覚（ハルシネーション）が発生していない箇所
を洗い出すための「レビュー」が必要になってきて、その後で修正案を検討して「AI」に指摘を伝えたところで「幻覚（ハルシネーション）」が発生するかどうかは神のみぞ知る世界なので、不毛なやり取りの繰り返しが発生するリスクが高いですからな...
「AI」については、一度壁にぶつかると、乗り越えられない頻度が高い。
一方、人間同士であれば、良くも悪くも、都度変化が起こり得る。
そして、皮肉なことに、「ソフトウェア開発」で作り出された「AIツール」は
オンライン掲示板のRedditでは、「私の新しい趣味：AIがMicrosoftの従業員を徐々に狂わせていく様子を見る」と題する投稿が話題となり、「AIが『直しました』と言い、人間が『いいえ、まだ壊れています』と言い、AIが変更を加えて『問題ありません、直りました』と言い、さらに数回繰り返すところが気に入っています」といったコメントや、「残念なことに、私もまさにこのパターンに従う人間の開発者と一緒に働いたことがあります」とのコメントのほか、「問題は、今後10年間でモデルが実際に改善され、実現可能になるという確かな証拠がないことです。
「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に - GIGAZINE
テストと研究はともかく、製品に導入するのは全く別物です。大手ソフトウェア企業は、株主の利益を満足させるために運営されています」など、未完成で不確かな製品を公開することに異議を唱えるコメントが付けられました。
「AIがMicrosoftの従業員を徐々に狂わせていく様子を見るのが趣味」というネットユーザーの投稿が話題に - GIGAZINE
⇧「ソフトウェアエンジニア」に対して最も被害を与えている気がする...
不確実性の高い「ソフトウェア開発」とは相性が悪いんだろうな...
「ソフトウェアエンジニア」の負担、いつになったら削減されるのだろうか？
正式リリースされたらしいGemma 3n とは
少し時間が経ってしまったのですが、
Googleが軽量かつ高性能なマルチモーダルAIモデル「Gemma 3n」を2025年6月26日(木)に正式リリースしました。正式リリースに合わせて詳細な仕様やベンチマーク結果が公開されています。
わずか2GBのメモリ使用量でスマホでの実行もOKな軽量オープンウェイトモデル「Gemma 3n」をGoogleが正式リリース、音声や動画の入力にも対応し日本語ももちろんOK - GIGAZINE
⇧ 上記にあるように、「Google」が「AI」の「モデル」で「Gemma 3n」というものを正式リリースしたらしいですと。
公式のドキュメントによりますと、
Gemma 3n モデルの概要
Gemma 3n は、スマートフォン、ノートパソコン、タブレットなどの日常的なデバイスでの使用向けに最適化された生成 AI モデルです。このモデルには、パラメータ効率的な処理の革新が含まれています。これには、Per-Layer Embedding（PLE）パラメータ キャッシュや、コンピューティングとメモリ要件を柔軟に削減できる MatFormer モデル アーキテクチャが含まれます。これらのモデルは、音声入力の処理、テキストデータ、画像データを特徴としています。
⇧ とあるのだが、
のどちらに分類される「モデル」になるのかが言及されていない...
「Hugging Face」の公開しているブログ記事によると、
⇧ とあり、一応、「Gemma 3n」は「小規模言語モデル（SLM：Small Lanaguage Model）」という分類になるということなんだろうか？
で、環境構築の方法が非常に分かり辛いのだが、
Gemma のコンテンツ生成と推論を実行する
Gemma モデルを実行する際には、次の 2 つの重要な決定を行う必要があります。1）実行する Gemma バリアント、2）実行に使用する AI 実行フレームワーク。これらの両方の決定を行う際の重要な問題は、モデルの実行に使用できるハードウェアです。
この概要は、これらの決定をナビゲートし、Gemma モデルの使用を開始するのに役立ちます。Gemma モデルを実行する一般的な手順は次のとおりです。
⇧ とあり、
- 1）実行する Gemma バリアント
- 2）実行に使用する AI 実行フレームワーク
の2つを選択する必要があるらしい。
「Phind」で「バリアント」について質問してみたところ、以下のような回答が返ってきた。
| No | 特徴 | バリアント（Variant） | バリアンス（Variance） |
|---|---|---|---|
| 1 | 基本的な意味 | 変種、変異、異なる形態 | 変動、ばらつき、散らばり |
| 2 | AIにおける役割 | モデルの異なる形態や実装 | モデルの予測精度のばらつき |
| 3 | 問題点 | 標準化の困難性 | 過学習のリスク |
| 4 | 対策 | ベースラインの設定 | 正則化技術 |
とりあえず、「Google」のドキュメントでは「バリアント」の定義が見当たらないので、推測になってしまうのだが、「Hugging Face」で公開されているモデルの種類を分けている要因の1つだとは思われる。
で、どの「フレームワーク」で、どの「バリアント」の「AI」モデルのサポートがされているかの対応が分からないのよね...
ちなみに、
⇧ 上記サイト様によりますと、「Google」が管理していない「AI」モデルであれば、
⇧ 画像にも対応しているものが公開されているようだ。
正式リリースされたらしいGemma 3nの環境構築を試してみたかったのだが...
と言うわけで、
- Webアプリケーション
- ネイティブアプリケーション
のいずれにしろ、「Linux」で稼働させることがメジャーな気がするので、「Gemma 3n」を構築する際に利用する「フレームワーク」としては、「Ollama」を利用することにする。
一応、「Ollama」の「Gemma 3n」の対応状況はというと、
⇧ 問題無さそうですと。
ちなみに、
- Webアプリケーション
- ネイティブアプリケーション
の違いについては、
⇧ 上記のページが参考になるかと。
脱線しましたが、手順としては、
で、動作確認については、「Gemma 3n」の手順ではないのだが、
⇧ とあるように、
の2つの方法が用意されているようなのだが、「2. Ollama ローカル ウェブサービス」については、「Google」のドキュメントで手順が省略されているらしく、
⇧ 上記サイト様によりますと、
ollama run [ollmaでダウンロードしてきたAIモデル]
⇧ 外部からのリクエストを受け付けるために「ollmaでダウンロードしてきたAIモデル」を起動しておく必要があるらしい。
最早、「Google」の公開している手順は、手順の意味をなしていないようだ...
一次情報の意味が無い哀しさよ...
後は、「ブラウザ」画面のような「Web User Interface」が必要な場合は、
⇧ 上記サイト様によりますと、別途、必要な手順がある模様。
まぁ、画面は「アプリケーション」毎に必要な構成が変わって来ると思うので、独自に開発することになる気がする...
脱線しましたが、「WSL 2（Windows Subsystem for Linux 2）」にインストールしている「Ubuntu 24.04 LTS」で試してみることに。
と思ったのですが、
⇧ 上記サイト様によりますと、「WSL 2（Windows Subsystem for Linux 2）」特有の問題なのか、ホスト側の「GPU driver」を参照する必要があるらしく、一般的な「Linux ディストリビューション」のような環境構築にならないらしい...
で、「Gemma 3n」は「Google」によって開発されたという認識なので、「Google Colaboratory」にダウンロードして稼働させられるものだと思っていたのですが、見事にエラーになるという...
と言うか、「Google Colaboratory」では、
>>> Installing ollama to /usr/local >>> Downloading Linux amd64 bundle ######################################################################## 100.0% >>> Creating ollama user... >>> Adding ollama user to video group... >>> Adding current user to ollama group... >>> Creating ollama systemd service... WARNING: systemd is not running WARNING: Unable to detect NVIDIA/AMD GPU. Install lspci or lshw to automatically detect and install GPU dependencies. >>> The Ollama API is now available at 127.0.0.1:11434. >>> Install complete. Run "ollama" from the command line.
⇧「サービス」として起動が禁じられている模様...
つまり、「Google Colaboratory」だと処理がブロッキングされてしまい、次の処理が実行できないので、「Ollama」による「AI」モデルのダウンロードもできない...
ちなみに、
⇧ 上記サイト様によりますと、マシンにダウンロードしない方法であれば動作確認できそうなのだが、いずれにしろマシンのスペックには依存するらしい。
となってくると、ローカル開発環境を構築するといった意味では、「VirtualBox」などの「仮想化ソフトウェア」を使って「仮想マシン」を用意していくしか無さそう...
何と言うか、「Google」のドキュメントに「事前要件（prerequire）」を記載しておいて欲しい気はする...
改めて、手順通りに実施できないとか、手順の意味が無いんだわ...
繰り返しになりますが、一次情報の意味が無いのよね...
必要な情報を探すのに疲弊するのよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
