AI

はじめに — 前回までと、今回のゴール 前回（続々編）は、UGREEN DXP6800 Pro に eGPU（RTX 2000 Ada 16GB）をつないで Ollama + Zed を構成し、「12B クラスは読めるけど思考できない」という壁にぶつかったところまででした。 今回のゴールはそこから一歩進めて、FlashML-org の FreeToken（MoE モデルの専門家をホスト RAM に置き、VRAM にはホットな専門家の LRU キャッシュだけを持つ推論エンジン）を同じ NAS の Docker で動かし、Zed のコーディング支援を実用レベルにすること。 [MacBook Pro / Zed] ─LAN─ [UGREEN DXP6800 Pro (Docker)] ├ ollama :11434 (既存・そのまま) └ freetoken :1919 (新設) ─ OCuLink / USB4 ─ [eGPU Dock + RTX 2000 Ada 16GB] ところが実際は、FreeToken のコンテナを組むこと自体より

RTX 2000 Ada を積んだ NAS の Ollama を LAN 越しに Zed から使い、インフラ実務タスク12本を実際に実行して採点した記録

生成AIを開発に利用するとき、「どのAIモデルが最も優秀か」という比較に目が向きがちです。 しかし、実際の開発では、AIモデル単体の性能だけで開発効率や品質が決まるわけではありません。 重要なのは、 どの開発ツールから、どのAIエージェントを使い、どのモデルに何の役割を担当させるか という組み合わせです。 現在、私の開発環境は、次の2系統で構成しています。 メイン環境： Ghostty＋Herdr＋Claude Code CLI 予備・バックアップ・事前調査環境： Zed＋Z.ai、またはZed＋Sakana AIのFugu Ultra メイン環境では、Claude CodeのOpus 4.8を実装担当として利用し、 Codexを独立したレビュー担当として組み合わせています。 この記事では、私がこの構成を選んでいる理由と、 AIモデル、AIエージェント、開発ツール、レビュー規約を どのように組み合わせているかを紹介します。 １．AIモデル、AIエージェント、開発ツールは別物 まず、混同されやすい用語を整理します。 分類 役割 私の環境での例 開発

はじめに 前回の記事では、UGREEN DXP6800 Pro に eGPU 経由で RTX 2000 Ada を載せ、Ollama を Docker 上で動かし、さらに Zed からローカルLLMへ接続するところまでをまとめました。 前回時点での到達点はこうでした。 Ollama は ollama/ollama:0.24.0 に固定 NVIDIA Driver は 535.261.03 GPU は RTX 2000 Ada 16GB qwen3:14b は 100% GPU で快適に動作 qwen3-coder:30b は本体RAM不足で本格検証できず UGREEN DXP6800 Pro の本体RAMを 64GB に増設予定 今回はその続きです。 NAS本体のメモリを 8GB から 64GB に増設し、qwen3-coder:30b がどこまで実用になるのかを試しました。 さらに今回は単なるベンチマークだけではなく、実際に Zed 経由でローカルLLMを使い、Sonnet と qwen3-coder:30b に同じようなコーディング課題を投げ

はじめに 前回、UGREEN DXP6800 Pro に eGPU 経由で RTX 2000 Ada を載せ、Docker から --gpus all でGPUを叩けるところまで持っていきました。今回はその続きで、本来の目的だった ローカルLLMをコーディングに使うところまでの記録です。 ゴールはこんな感じ: NAS本体で Ollama を常時稼働させる ブラウザからは Open WebUI で叩く エディタ Zed からも繋いで、コーディング補助に使う ……が、これがまた一筋縄ではいかず、CUDAエラーで全モデルが起動しないという壁にぶつかりました。結論から言うと、原因は「Ollamaが新しすぎたこと」でした。同じ構成でハマっている人の役に立てば嬉しいです。 最終的に安定した構成はこちら: UGREEN DXP6800 Pro └ NVIDIA Driver 535.261.03 (CUDA 12.2) └ RTX 2000 Ada (VRAM 16GB) └ Docker ├ ollama … ollama/ollama:0.2

Microsoft 365 Copilot に「Cowork」っていう自律エージェントが乗ってきました。中身は Anthropic の Claude。メール送ったり予定入れたり資料作ったり、指示するだけで勝手に動いてくれるやつです。すごい。 で、自社サービスに AI アシスタントを積んでる身としては当然こう思うわけです。「これ、自分のアプリから呼べたら最高では？」 結論から言うと…呼べませんでした。しかもその過程で、もっとデカい「課金が変わる話」まで掘り当ててしまったので、まとめて共有します。 そもそも Cowork って何？ ざっくり言うと、Copilot がただ喋るだけじゃなく「実際に作業する」モードです。 やってほしいことを伝えると、勝手にプランを立てて動く メール・予定・Word/Excel/PowerPoint・Teams 投稿あたりを実行 1ターンで終わらず、数分〜数時間かけて複数ステップを進める 勝手に暴走しないように、要所で「これやっていい？」と確認を挟む 使えるのはブラウザ（m365.cloud.microsoft）・デスクトッ

はじめに 前回の記事では、UGREEN DXP6800 Pro に eGPU(RTX 2000 Ada)を載せて、Docker から --gpus all で叩ける状態まで持っていった話を書きました。今回はその続編、というか「続きを動かそうとしたら、また別のところで派手に詰まった」記録です。 結論から書くと、最終的にはこんな構成で安定運用に入れました。 UGREEN DXP6800 Pro UGOS Pro Kernel: 6.12.74+deb12-amd64 NVIDIA Driver: 535.261.03 GPU: NVIDIA RTX 2000 Ada Generation (VRAM 16GB) Docker Compose: Ollama + Open-WebUI モデル領域: 14.5TB HDD (RAID6) の上に手動 LV + ext4 SSD 領域: コンテナ実行ベースとして温存 ただ、ここに辿り着くまでに「Open-WebUI からモデルが見えない」という一見シンプルな症状を入口に、Docker のネットワーク、SSD

はじめに 正直に言うと、最初は「NASにeGPUを繋いでDockerからGPUを使う」って、もう少し簡単に終わると思ってたんです。 でも実際にやってみたら、ブートが飛んだり、ドライバーのバージョンが噛み合わなかったり、/boot が256MBしかなくて initrd の更新で詰んだり……正直、何度か「もう諦めて素直にWindowsマシンに刺すか」と心が折れかけました。 それでも最終的には、UGREEN DXP6800 Pro 上で eGPU 接続の RTX 2000 Ada を Docker から --gpus all で叩ける状態まで持っていけたので、ハマりどころを含めて記録として残しておきます。同じ構成で詰まっている方の参考になれば嬉しいです。 最終的に到達したのはこんな環境です。 UGREEN DXP6800 Pro UGOS Pro Kernel: 6.12.74+deb12-amd64 (Debian backports) NVIDIA Driver: 535.261.03 GPU: NVIDIA RTX 2000 Ada Genera

目的 前回の検証では、OPSNOTE（当社開発中の手順書 SaaS）におけるAzure上の自社ホストAIモデルに対して、性能比較を行い、現時点ではqwen2.5:14bとClaude Haikuでは、勝負にならないことまではわかりました。 今回は、同じローカルLLMに対して、Macbook Pro M2 16GBのモデル上で、ollama経由での応答を比較したいと思います。 先に結論 どのモデルもClaude Haikuレベルに達していない。 ローカルLLMを使用する場合には、VRAM32GB以上を搭載したモデルが稼働できるレベルに至らないと、評価の土台に乗ってこない。 環境 動作環境：Macbook Pro M2 16GB ollamaバージョン：0.9.2 比較モデル：gemma4:4b, llama3.1:8b, qwent3.5:4b 前提：AIモデルに対する事前チューニング無し 比較する文字列 UbuntuにPostfixをインストールし、特定のIPアドレスのみを外部リレーするサーバを構築したい。手順を教えて。 あなたは IT...

背景 OPSNOTE（当社開発中の手順書 SaaS）の AI 機能は標準で Anthropic Claude API を使う。一方で「顧客データを外部 API へ送れない」テナント要件が発生する可能性を考慮し、自社 Azure サブスクリプション内で完結する LLM 経路を SKU として用意したい。Azure Japan East の T4 GPU 上で Qwen2.5:14B-Q4 を動かし、Claude Haiku 4.5 / Sonnet 4.6 と横並びで評価した。 評価は 2 段階で実施した。 機械計測 PoC（性能・コスト・5 シナリオ × 単発比較） 人手運用テスト（実テナント上で 21 件の業務シナリオを実施・本番経路で tool calling 含む） 結論を先に書くと、機械計測 PoC では Haiku 比 106% で「採用可」、人手運用テストでは 42% で「不合格」という逆転が起きた。ここではその差がどこから来たかをまとめる。 １．機械計測 PoC（先行） 検証構成 インフラ: ACA Serverless GPU..

こんにちは！最近はなぜかブログモチベが高いです。 本題ですが、ここ1、2年で私の働き方は大きく変わりました。 と言っても会社の制度が変わったり、業務時間が変わったりしたわけではありません。 そう、AIによって業務の効率が大幅に改善したのです。 分からないことが業務で生じたとき、必ず私はcopilot君（MicrosoftのAI）に 「こういう状態のときにこうなるのはなぜ？」と聞きます。 すると割と高精度な回答が返ってきて、言われたとおりに検証してみると解決するんです。 エラーが出ることもありますが、都度そのエラー内容をcopilotに問い合わせれば 修正してくれます。そうして結果的には問題が解決してしまうんです。 でもふと思います。 「あれ、これってエンジニアとして成長してるって言えるのかな。」 他人からみればちゃんと成長しているようには見えるかもしれないです。 しかし、自分自身からするとあまり成長が実感できません。 だってAIが出した回答を元に解決しているのですから。。。 入社したての頃は世間的にみても「AIって意味の分からない回答してくるよね

何にAIを使っているのか 当社は様々なSaaSを使っています。特に利用頻度が高いものは以下の６つです。 見積、請求、入金を管理するboard プロジェクト管理や進捗管理、課題管理などを行うwrike 社内の脱Excel化のためのkintone 会計、勤怠などを管理するfreee 社内やお客様との情報連携をするMicrosoft TeamsやSlack 様々ファイルベースのデータを管理するbox こういったSaaSは、横の連携があまり得意ではありません。そのため、業務として見るとツール間のデータ連携は人の手を介す必要がありました。例えば、以下のようなイメージです。 旧来の方法（例１） wrikeで取得した保守タスクや案件ごとの工数をAzure Automationで月初にCSV出力 kintone上のアプリに手動でCSVインポート 旧来の方法（例２） boardで取得した計上案件の情報をAzure Automationで月初にCSV出力 kintone上のアプリに手動でCSVインポート 旧来の方法（例３） 販売代理店からもらった見積もりをPDFでも