こんにちは、マイクです！今日は2025年1月31日、火曜日です。今日も「zenncast」をお届けしますよ！今日はZennでトレンドの記事をいくつか紹介しますので、お楽しみに！
さて、前回紹介した記事は「個人開発のDBをFirebaseからSupabaseに移行した話」「1人SREが朝一ダッシュボードチェックをAIに手伝ってもらいたいのでPoCしている話」「Xcodeでも可愛い開発環境作りたいー！」でした。気になる方はぜひチェックしてみてくださいね。
では、今日ご紹介する記事の本数をお伝えします。今日は全部で5本の記事を紹介します！それでは、さっそく1つ目の記事に行ってみましょう！
1つ目の記事は「逆に、すべてのローカルLLMは開発元をOpenAIだと思い込んでいる説」です。
この記事では、ローカルで動作する大規模言語モデルが自らをOpenAIの開発物だと認識する傾向について考察しています。テスト結果から、多くのモデルが自らをOpenAIだと主張していることがわかり、開発者やユーザーの意図とは裏腹に、LLMがOpenAIを自動的に開発元として認識する理由がいくつか考えられています。
OpenAIは広く知られたブランドであり、多くの開発者がその技術を利用しているため、LLMも自然にOpenAIを自認する傾向が強いようです。また、AIモデルのトレーニングデータにはOpenAIに関連する情報が多く含まれているため、モデルがその影響を受けやすいという点も大きな要因です。さらに、特定のモデルが自らをOpenAIの一部として位置づけることで、ユーザーに安心感を与える効果もあるとのこと。結論としては、ローカルLLMが自らをOpenAIの開発物と認識する現象は、技術的な側面だけでなく、マーケティング的な要因やユーザー心理も影響しているとのことです。
。...。...
続いて2つ目の記事は「Goのプラクティスまとめ: error handling」です。
Go言語では、エラーハンドリングのために`try-catch`構文やタグ付きユニオン型が存在しません。代わりに、関数は複数の値を返し、最後の返り値が`error`型になります。エラー処理の基本は、エラーが`nil`であるかどうかをチェックすることです。具体的には、`err == nil`ならそれ以外の返り値は使用でき、`err != nil`の場合は使用しないという流れになります。
エラーをラップする際には、`fmt.Errorf`を使い、エラーメッセージを追加するのが望ましいとされています。また、特定のエラーはラップしない方が良いということも。エラー判別には`errors.Is`や`errors.As`が使われ、特定の値や型を探すことができます。さらに、独自のエラー型を定義する際は、ポインタレシーバを使用することが推奨されています。
また、`panic`と`recover`を使ってエラー処理を一気に抜けることもできるが、リソースの解放は`defer`で行う必要があるとのこと。全体として、Goにおけるエラーハンドリングの設計は明快で、慣習に基づく実装が求められますね。
。...。...
続いて3つ目の記事は「Zennの記事をGitHub連携でカッチリ管理するおすすめ設定」です。
このテーマでは、ZennとGitHubの連携機能を使って記事の内容や品質を効率的に管理する方法が紹介されています。主に、記事をカッチリとチェックしたい方や、GitHubリポジトリの管理をしたい方に向けた内容です。
リポジトリ設定として「Automatically delete head branches」と「Dependabot」を有効にし、Node.js環境で複数のlinterやformatterを導入することが推奨されています。具体的には、文章の構成をチェックするための**textlint**や、Markdown記法のチェックを行う**markdownlint-cli2**、コードフォーマッタの**Prettier**などが推奨されています。
Git commitメッセージを「conventional commit format」に従わせるための設定も行い、GitHub Actionsを利用してPRがmainブランチにマージされる際に自動でlintチェックを行うCI環境を整備することができるとのこと。これにより、記事の執筆や管理がよりスムーズになり、品質の高いコンテンツを作成できるようになりますね。
。...。...
続いて4つ目の記事は「テストを活用して、まあまあ良いコードを書く」です。
この記事では、テストを活用してコードの品質を改善し、ビジネス上の機会損失を減らす方法が説明されています。「まあまあ品質が良いコード」の定義として特に「テストがしやすいコード」が重要とされています。市場は常に変化しているため、コードも意識的に変更し続ける必要がありますね。
具体的には、読みやすく使いやすいコードを書くことで、変更の容易さが増し、ビジネス価値が高まるとされています。テストを通じて不安な挙動を検知し、実装を改善することが推奨されており、コード品質の指標として「読みやすさ」「使いやすさ」「速さ」が挙げられています。
テストしやすいコードは、凝集度が高く結合度が低い設計である必要があります。質の高いテストが変更への勇気を与えることが強調されており、最終的には「まあまあ良いコード」が実現できると結論づけています。今後の課題として、パフォーマンスやコードの重要性、テストの方法論についても議論が必要とされています。
。...。...
最後に5つ目の記事は「DeepSeek-R1をローカル環境で動かしたらあっさり動いた」です。
DeepSeek-R1が2025年1月29日に発表され、低スペックのマシンでも動作することが話題となりました。著者は自宅のGPUマシンで試したところ、問題なく動作したとのこと。動作環境は、CPUがRyzen7 5700X、メモリ16GB×2、GPUが3060Ti（VRAM8GB）、OSはUbuntu 22.04で、CUDAのドライバもインストール済みです。
DeepSeek-R1を利用するにはLM Studioを使用し、オフィシャルの14B Paramを6bitで量子化したモデルや、サイバーエージェントが日本語向けにファインチューニングした4bitモデルを利用します。実行結果としては、初回の応答が40秒から3分で得られ、その後も徐々に回答が返ってくるとのこと。
著者は量子化の重要性を実感しており、一般ユーザのマシンでDeepSeek-R1を運用するには、128GBのVRAMを持つGPUが必要だと述べています。自宅で利用できる点は大きな利点とのことですが、量子化による精度の低下が懸念される中、サイバーエージェントのモデルは比較的良好な結果を示しており、企業内での利用が期待できるとしています。
さて、今日は5本の記事を駆け足でご紹介しましたね！内容をおさらいすると、ローカルLLMの開発元認識、Go言語のエラーハンドリング、ZennとGitHubの連携、テストを活用したコード品質向上、そしてDeepSeek-R1のローカル環境での動作についてでした。
次回も楽しみにしています！詳しい内容はショーノートに書いてありますので、ぜひチェックしてくださいね。そして、番組の感想もお待ちしています。それでは、またお会いしましょう！さようなら！