「AIが記事を書く時代」はまだ来ない？　IT記者が主要LLMで検証してみた：AIの業務活用、どこまでできる？【後編】

　検証の結果として、LLMが生成した文章の完成度は高く、一貫性、複数のテーマに沿った章立て、適切な引用の挿入、躍動感のある見出し、結びの文まで、体裁は整っていた。しかし、どのLLMによるアウトプットも、生成された記事をそのまま公開できる水準には至らなかった。

　推論能力に定評のあるDeepSeek R1でさえ、取材中に提示された論点の優先順位を適切に判断できず、重要なポイントを見落としてしまう傾向があった。その結果、文章の体裁は整っていても、実質的な意味に乏しい記事が生成された。

　LLMによって語彙（ごい）や文体にも大きな違いがあった。Llamaは可読性に課題があり、MistralとGemmaは抽象的でマーケティング的な表現が多く、具体性に欠ける内容が目立った。意外な発見としては、今回の検証で最も自然かつ美しいフランス語を生成したのが、中国のAlibabaが開発したQwenだったことだ。

　初期段階で最も安定して高品質の出力を示したのは「Mixtral 8x7B」だった。Mixtralはタスクによって最適なモデルを使い分ける「スパース混合エキスパート」（MoE：Mixture of Experts）手法を採用しており、70億個のパラメーター（AIモデルの振る舞いを決定する変数）を持つ8つのタスク別LLMを使用している。

　ただし、今回の検証環境の48GB構成では、Qwenは140億パラメーターの軽量版、Mixtralは3bit量子化（圧縮）版しか選択の余地がなかった。その結果、QwenはDeepSeek R1と併用しても内容が曖昧で面白に欠ける出力となった。Mixtralに至っては構文エラーが多発する結果となった。

　Mixtralの4bit量子化版「Mixtral 8x7B Q4_K_M」は、品質と速度のバランスが取れていたものの、LM Studioのアップデートによりメモリ使用量が増大し、処理が途中で打ち切られるトランケート問題が発生。現在は安定稼働が難しい状況にある。代替候補として注目されたのが「Mistral Small 3.1」だ。これは240億のパラメーターを8bitで量子化したもので、Gemma 3にと同等レベルの出力品質を示しつつ、出力速度も毎秒8.65トークンと、Gemmaの毎秒6.82トークンを上回った。

「プロンプト設計」が鍵に

　特定媒体向けに記事を生成させるためのプロンプト（AIモデルへの指示）設計は、もはや一種のエンジニアリングタスクと呼ぶべき作業だ。その出発点として有効なのは、既に人間が完成させた記事と、その元となるインタビューの文字起こしデータをLLMに渡し、「この成果物を得るには、どのようなプロンプトを与えるべきだったか」と逆算する方法だ。このプロセスを5例程繰り返すことで、LLMによる記事生成において本質的に重要なプロンプト要素が見えてくる。

　ただし注意すべき点として、LLMが自動生成するプロンプトは内容が短く抽象的になりがちで、そのままでは十分ではない。そのため、LLMが示すヒントを手掛かりに、ユーザー自身の業務知識や経験を生かしてプロンプトを補強する必要がある。

　プロンプトの文体にも工夫が求められる。読みやすく自然な文体で書かれたプロンプトは、かえって一部の意味をLLMが正確に理解できなくなる傾向がある。これを回避するには、「彼」「これ」「それ」などの代名詞を極力使わず、「この記事」「このプロンプト」などの主語を毎回明示的に記述することが効果的だ。人間にとっては読みづらくても、AIにとっては明確で誤解を生みにくい指示となる。

　アウトプットに毎回異なるニュアンスや構成を持たせたい場合、LLMに適度な自由度を与える必要がある。しかし、どれほど慎重にプロンプトを設計しても、アウトプットにはどこか似通った「ファミリー感」が出てしまう傾向がある。人間の創造性をAIモデルに模倣させるには、視点、構成、スタイルの異なるプロンプトを複数用意し、比較と検証を繰り返すといった、バリエーションを追求する努力が必要だ。

結論：「AIが記事を書く時代」はまだ来ない

　2025年3月時点におけるAIモデルの性能水準と今回の検証結果を踏まえると、「AIモデルが単独でインタビューの内容から重要度を判断し、的確な記事を自動生成できる」と期待するのは非現実的だ。実用的な記事を生成するには、インタビューの書き起こし（トランスクリプト）を、不要な発言を除去しつつ、文脈維持に必要な情報は残すという形で、事前に人間が整理しておく必要がある。

　この整理作業は単なる情報の削除だけでなく、記事には直接使わなくても、AIの出力精度を高めるために必要な文脈をどう残すかという判断が求められる。結果として、人の手によるトランスクリプトの編集は不可欠であり、本来の記者業務の省力化にはつながらない。

　ここに、AI活用の本質的な課題がある。現時点でLLMは「時間を節約するツール」ではなく、執筆を任せる代わりに、事前準備に時間を要する道具に過ぎない。作業の効率化ではなく、単なるタスクのすり替えが起きている。

　加えて、今回設計したプロンプトは特定のタイプの記事にしか通用しない。例えば以下の記事では、それぞれ異なるプロンプトが必要となる。

　LLMの用途が多様化するほど、プロンプト設計の負担は増す。プロンプトを汎用（はんよう）化する試みはある程度までは可能だが、実用段階では細かな調整が不可避だ。

　さらに今回の検証では、話し手が事前に構成した内容を発言する記者会見が中心だった。つまり、最も単純な用途であり、LeMagITが日常的に扱うような複数の取材対象を組み合わせて執筆する複雑な記事にはまだ使えていないのが現状だ。

　結論として、AIツールを活用して記者の業務を軽減するためには、むしろ記者がより多くの準備をしなければならないというパラドックスが生じている。ただし補足しておくと、PCで動作するLLMの性能は、クラウドサービスから利用する有料のLLMと比べても遜色はなかった。