ワークアウト

生成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エージェント、開発ツールは別物 まず、混同されやすい用語を整理します。 分類 役割 私の環境での例 開発

社内のコードとログを海外のLLM SaaSに送らずに、エディタでAIコーディングを使いたい。 この当たり前の要望が、実は技術的にかなり難しいという話と、それを2つのクラウドで実測して白黒つけた記録です。 生成AIをコーディング業務に組み込むとき、多くの企業が最初にぶつかる壁が 「入力したコードや社内ログが、海外のデータセンターで処理されるのではないか」という懸念です。 いわゆるデータ越境リスク。契約や規約で「学習には使わない」と書かれていても、 物理的にどのリージョンで推論(inference)が実行されるかは別問題として残ります。 私たちはこのテーマに対して、2つのクラウド上で検証リポジトリを作り、 「書類上できるはず」を一切信用せず、すべて実測で判定するという方針で取り組みました。 本記事はその2つのリポジトリ ― Azure版の editor-openai-foundry と、 AWS Bedrock版の editor-claude-bedrock ― をたどりながら、推論の国内完結がどこまで実現できるのかを整理します。 この記事で答えるこ

事業計画は、作成して終わりではありません。本当に重要なのは、計画に対して実績がどのように推移しているのかを継続的に確認し、必要なタイミングで次の打ち手を判断できる状態を作ることです。 一方で、実際の業務では次のような課題が起こりがちです。 事業計画はExcelで管理している 実績データは会計システムに入っている 売上見込みは営業管理システムに登録されている 月次でデータを集めるたびに手作業が発生する 経営判断に必要な数字を確認するまでに時間がかかる そこで今回、当社では来期事業計画をもとに、予実管理と売上予測を行うWebアプリケーションを構築しました。 この記事で紹介する内容 予実管理 クラウドへのデプロイ 別クラウド製品からのデータ取得 1. 予実管理：計画を“見える化”し、実績との差異を把握する 本プロジェクトの出発点は、来期事業計画を月次で管理できる形に整理することでした。 売上、原価、販管費、営業外損益を月ごとに管理し、損益計算書まで自動集計できる構成にしています。 主な管理項目 売上計画：フロー売上、ストック売上 原価計画：販売原価、保

匿名化ケーススタディ：基幹システムにおけるリソース割り当て機能の性能改善 ※ 本記事は、実プロジェクトの技術的な学びをもとにした匿名化ケーススタディです。 業種・企業名・実際の機能名・APIパス・テーブル名・カラム名などは、公開用に抽象化しています。 ある大規模基幹システムの再構築プロジェクトにおいて、特定業務画面（リソース割り当て画面）で利用する候補一覧 API /api/v1/resource-assign/candidates に性能課題がありました。 症状は、ページ送りをすると応答が遅くなることです。浅いページでは許容範囲でも、深いページでは約900msまで伸び、実務担当者の操作テンポを落としかねない状態でした。 今回、sakana.ai の fugu ultra は、この課題に対して独立に方針検討を行い、実機検証の進め方と改善案を提示しました。 最終的には、当初想定していた大きなDB変更や複雑な二段化クエリではなく、1ファイル・実質10行の最小修正で、深いページの応答を 約900ms → 約380ms台へ改善しました。 このケースで特に

AIを使った開発環境では、最近よく「AIモデル」「AIエージェント」「スキル」「ツール」という言葉が出てきます。 ただ、これらは似ているようで役割が違います。特にZedのようなAI対応エディタを使うと、AIがコードを読んだり、ファイルを編集したり、ターミナルでコマンドを実行したりするため、「結局、何が何をしているのか」がわかりにくくなります。 この記事では、Zedを例にしながら、AIモデル・AIエージェント・スキル・ツールの関係を整理します。 実際にはコーディングだけなく、クラウドインフラを扱う上で、コマンドによるログ収集や取得したログの解析などといったインフラエンジニアにとっても、AIエージェントの恩恵を受ける場面は多くなっています。 まず結論 一言でいうと、次のように理解するとわかりやすいです。 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）・デスクトッ

AI コーディングエージェントの API コストを、開発体験を変えずに削減する。 背景：AI コーディング常用で見えてきた「文脈コスト」 社内では日常的に AI コーディングエージェント（Claude Code）を開発に組み込んでいる。 生産性は確実に上がる一方で、エージェントが ツール実行結果・ビルドログ・会話履歴 を 繰り返し LLM へ送り込む構造上、入力トークンが膨らみやすい。 実装そのものより「文脈の運搬コスト」が積み上がっていく――これが今回の最適化の出発点である。 Headroom とは Headroom は、LLM へリクエストを送る前にコンテキストを圧縮するローカルプロキシ。 エージェントと API エンドポイントの間に挟むだけで、ツール出力やログといった 「冗長だが意味は保てる」テキストを縮めてから上流へ渡す。 動作位置：http://127.0.0.1:8787 でローカル待受。/v1/messages を Anthropic、/v1/chat/completions 系を OpenAI へ中継。 圧縮エンジン：ONNX..

はじめに 前回の記事では、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）の 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..

何に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でも

当社が利用しているfreeeやboardから必要なデータを取得し、会社の傾向を掴むためのデータを抽出しようとコンテナでアプリを作りました。 アプリは、チームみらいさんのGithubレポジトリ（https://github.com/team-mirai/marumie）をベースにして一分必要な昨日や図表を表示するように、コードを書いています。 データ解析だけを目的としたSaaSは徐々に衰退し、基幹業務に必要となるSaaSはデータプラットフォーム（単なるデータ置き場）となる可能性はあると思っています。その場合、API利用料は徐々に上がっていくんでしょうね。 今回作成したアプリはコンテナ化していることもあり、社内のみで運用を想定していましたが、fly.ioを利用したのは、安いコンテナサービスを利用して見たいという好奇心です。 月に数百円で利用できるか、を試してみたいと思います。 前提条件 Dockerfileはローカルテスト済みのものを使用する アプリはEntra ID認証を行い、社外の人がアクセスできないようにする githubレポジトリをローカルに

M365 Agent Toolkitを使ったTeams アプリを作ったので、記事にしました。 前提条件 処理のメインとなるJSONファイルをフラット化し、Excel形式に変換する部分は事前に作成済み。 アプリアイコンもAIに機能名とサイズを指定して、作ってもらいました。...

Azure Automation上のスクリプトをローカル環境でリモート実行するときに、少し時間が経つといつもつまずくことを備忘として記載します。 以下のURLにある通り、環境変数で設定しろ、書いてあるんですが、これが曲者。。。...

目的 前回「Azure Container InstancesでAP-DB構成を組んでみる」で、ACIを使ったコンテナ構成を組んでみましたが、Dockerよりの機能がためか、スポット的な利用であればいいのですが、絶えず動かしておくには少しコストが掛かりすぎる印象です。...

目的 Azure上のコンテナサービスは複数ありますが、今回は複数のインスタンスを（恐らく）一つのホスト上にデプロイし、Web APサーバからDBサーバへのデータ追加をテストしてみたいと思います。 作業の流れ Dockerfileの作成...

MS Teamsにメッセージを送る方法を模索していましたが、意外に簡単にできたので、”表形式”で送ることにも挑戦してみました。 　私は特定の株の前日から１週間分を取得して、所有株価との差分を出すことにしました。 　Teamsへメッセージを送るのは、以下の手順が必要です。...

Azure AutomationでPython3を動かす手順をご紹介します。難しい手順ではないですが、MSサイトは初学者には敷居が高いので。 はじめに 公式サイトは、こちらです。 https://learn.microsoft.com/ja-jp/azure/automat...