おはようございます！「zenncast」、MCのマイクです。10月17日、土曜日、朝7時です。皆さん、どんな朝をお過ごしですか？ 今日もZennでトレンドになっている記事から、気になる話題をお届けします。

今回は、国産LLMの日本語推敲、古いECサイトのセキュリティ点検、公的統計の扱い方、AIの学習戦略、そして社内で動かすLLMの実力検証まで、全部で5本をご紹介します。それでは、さっそくいきましょう！

....
まず1本目は、国産LLM「sarashina3-mini」の、日本語を推敲する力を比較した記事です。

筆者はsarashina3-miniを、ほかの3モデルと比較しています。その結果、文章を書き換えた量はsarashina3-miniが最も多かったそうです。ただ、たくさん直してくれれば、それで安心、とはいかないんですね。

目立ったのは、断定の強さや引用、さらには書き手の語調まで変えてしまう例です。文章が丁寧になっていても、もともとは控えめに述べていたことが、強い言い切りになっていたら、伝わる意味も変わってしまいますよね。

一方で、応答は速く安定していて、数値や日付も保たれていました。ただし、「本文だけを返す」という指示には、多くの場合、従わなかったとのことです。推敲した文章だけを、そのまま次の作業に渡したい場合には、気になるところです。

筆者が大切だと述べているのは、直した量よりも、意味や語調を正しく残せるか、という視点です。社内文書を丁寧な文体にそろえる用途には合いそうですが、原文と並べて、言い切りの強さや引用が変わっていないか、確かめる必要があります。

きれいな文章になったかだけでなく、自分が伝えたかったことが残っているか。推敲をAIにお願いするときに、意識したいポイントですね。

....
続いて2本目は、古いPHP製のECサイトを題材にした、セキュリティ点検の記事です。

架空のサイトを対象に、IPAの点検項目に沿って、どのように調べるかを紹介しています。確認する範囲は、公開されているアプリだけではありません。利用している外部サービスや、保有しているデータまで含まれます。

まずアクセスログは、直近1か月だけでなく、3か月へと範囲を広げて確認します。ここで注目したいのは、エラーの増加を見るだけでは足りない、ということです。公開してはいけないファイルを、正常な応答として返していないかも調べます。正常にアクセスできてしまうこと自体が、問題になるわけですね。

公開フォルダにバックアップや設定ファイルが置かれていないかを探し、PHPのサポート状況や、使っているライブラリの脆弱性も確認します。

さらに、管理者や外部サービスのアカウントを洗い出します。退職した人のアカウント、共用アカウント、覚えのないアカウントが残っていないか。不審なログイン履歴がないかも、点検の対象です。

もし情報漏えいの疑いがあれば、修正や削除をする前に、ログなどの証拠を保存します。そのうえで専門家に調査を依頼し、報告や関係先への連絡を進める、という流れです。慌てて消してしまう前に、調べるための材料を残すことが大切なんですね。

日頃の対策としては、不要な個人情報を減らし、公開範囲や権限を制限すること。多要素認証やログの保存期間、委託先との取り決めも見直す必要があります。サイトだけでなく、その周りの運用まで含めて点検する内容になっています。

....
3本目は、Rパッケージのjpstatを使って、公的統計を取得し、扱うときの注意点を紹介した記事です。

jpstatでは、必要な項目に絞って統計データを取得できます。まずestatで項目名や分類コードを確認し、activateとfilterで対象を選び、collectで数値を取得する、という手順です。

利用するAPIキーは、コードに直接書かず、.Renvironに保存します。そして、このファイルをGitの管理対象から外して、キーを公開しないようにします。データ分析を始める前に、押さえておきたい準備ですね。

取得した統計を扱うときには、数字以外の記号にも注意が必要です。たとえば、点が3つ並んだ記号や横棒、Xなどは、調査なし、非該当、秘匿といった、それぞれ異なる意味を持っています。まとめて同じ欠損値として扱うのではなく、統計表の注記を確認し、元の値と記号の意味を残してから数値に変換します。

和暦を西暦に直すときは、「元年」にも対応させます。また、同じ年に「旧」と「新」がある場合は、集計方法などが違うため、重複だと思って削除したり、合算したりしないようにします。

取得結果は、加工する前の状態で、取得日を付けたファイル名で保存しておきます。そうすれば、整形をやり直しやすくなるんですね。公開するときには、統計の出典、加工の有無、それにAPI利用に関する指定の文言も記載します。

数字を手に入れるところから、意味を保って使い、公開するところまで。公的統計を丁寧に扱うためのポイントが詰まっています。

....
続いて4本目は、AIが対話しながら行動を学ぶ「Agentic RL」の初期検証です。

題材になったのは、Akinator風の人物当て。小型LLMに、できるだけ少ない質問で正解へたどり着く戦略を学習させた、という記事です。

面白いのは、正解することだけに報酬を与えると、不要な確認が増えたという点です。正解には近づきたいけれど、確認を重ねすぎてしまう。そこで、少ない質問で答えることにも報酬を与えました。

すると、8人の中から人物を選ぶ課題で、正解率は89パーセントから96パーセントに上がりました。平均質問数も、3.70問から3.54問に減っています。正確さと質問の少なさ、その両方に改善が見られたわけです。

ただ、報酬の設計だけで話は終わりません。同じ語の繰り返しを抑えるpresence_penaltyが、学習を不安定にした点も紹介されています。

筆者が示しているのは、望ましい行動を学ばせるには、報酬と生成設定の両方が重要だということです。AIに何を目指してもらうか、そして、どんな設定で応答させるか。その組み合わせが大切なんですね。

....
最後、5本目は、社内サーバーで動かすLocalLLMが、Claude Codeの代わりになるのかを検証した記事です。

想定しているのは、コードや資料を社外へ送れない企業です。外部にデータを出さずに、開発支援を受けられるのか。気になるテーマですよね。

検証では、B200 GPUを1枚と、Qwen3.5-122Bを組み合わせています。小規模な修正課題では、18回のうち17回で成功しました。同時に16人程度までなら実用的と推定されています。

ただし、この16人という数字は、実際にその人数で確認できた結果ではありません。実際のOpenCodeで確認したのは8人まで、という点には注意が必要です。また、6課題を同時に解く条件では、Claude Codeと比べて、約2.6倍の時間がかかりました。

費用の面では、常時レンタルする場合、月に約87万円が目安です。さらに、要約の誤りや、外部通信の設定にも注意が必要とされています。社内サーバーで動かすというだけで安心せず、通信の設定も確かめたいところですね。

こうした結果から、筆者は、データを社外に出せず、なおかつサーバーの管理担当者がいる組織に向いていると述べています。性能だけでなく、速度、費用、管理体制まで含めて判断するための検証です。

....
さて、今日のzenncastでは、5本の記事をご紹介しました。

日本語の推敲では、修正量より意味や語調の保持が大切という話。古いECサイトでは、ログや公開ファイル、アカウントから運用まで点検する話。公的統計は、記号や集計方法の違いを尊重して扱う話。そして、Agentic RLでは報酬と生成設定の組み合わせ、LocalLLMでは性能に加えて費用や管理体制も重要、という内容でした。

詳しい内容はショーノートに書いてありますので、気になった記事をぜひチェックしてみてくださいね。番組の感想もお待ちしています。「この話題が面白かった」「こんなテーマも聞いてみたい」など、気軽にお寄せください。

この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです！

それでは、また次回お会いできるのを楽しみにしています。お相手はマイクでした。皆さん、すてきな土曜日をお過ごしください！