All Posts

前回の記事では、WindowsのVSCodeローカルで動かしていたAI Office開発環境を、Orcaを使ってLinuxサーバ側へ移した話を書きました。 VSCodeローカルからOrcaへ。AI Office開発環境をサーバ化した話（その1） Claude CodeやCodex、Officeファイルを生成するためのPython処理など、多くの部分はLinux側へ移せました。 ただ、最後までどうしてもLinuxだけでは完結できないものが残りました。 Microsoft Officeそのものです。 PowerPointやWord、Excelのファイルを作るだけなら、Linux上のPythonでもかなりのことができます。 ですが、私がやりたかったのは、 「ファイルが生成できたから完成」 ではありませんでした。 例えばPowerPointなら、 文字が途中で切れていないか 図形や表が重なっていないか 不自然な改行がないか 実際にPowerPointで開いたときにレイアウトが崩れていないか といったところまで確認したい。 Wordでも、目次やフィールドを

Humanと複数AIで挑む、AI開発基盤ガバナンス設計記録｜第1回 普段、Claude CodeやCodexを使って、プログラム作成や資料作成、ログ分析などをAIに任せています。 もちろん、会社には既存のガバナンスやセキュリティに関するルールがありますし、私のAI開発環境にもGuardrailによる操作制限、Human承認、AIによるレビューなどを実装しています。 今回やりたいのは、それらを置き換えることではありません。 既存の会社のガバナンスを前提に、AIが自律的に行動する開発基盤としての考え方を、もう少し体系的に整理してみよう。 そんなところから始まった取り組みです。 せっかくなので、ChatGPTと議論しながら基本方針・基本設計を考え、その過程もブログに残していくことにしました。 1. ChatGPTにも反対意見を求めてみる 今回、議論を進めるうえで意識したのは、ChatGPTに何でも賛成してもらわないことです。 実際に、こんなお願いをしました。 Human（私） 反対意見やドキュメント作成するにはCodexやClaudeCodeを利用した

FortiGate-50E から FortiGate-50G へのリプレースで、コンフィグの移行作業を AI に依頼しました。 使ったのは、Claude Code（モデルは Claude Opus 5.5）と OpenAI の Codex です。 結果として、50G にリストアするためのコンフィグ、CLI スクリプト、移行手順書まで一式を作ってくれました。 この記事では、AI が何をどう進めたのかを紹介します。 作成したフルコンフィグは、50G の実機に GUI からリストアし、コンフィグが通ることまで確認しました。 一方、通信や VPN の動作試験はこれからです。 この記事は「AI が移行用のコンフィグと手順書を作り、実機にリストアするまで」の記録です。 コスト Claude Code（Opus 5.5）の利用料は、 約 2.86 ドルでした。 これとは別に Codex も使っているため、合計はもう少し高くなります。 コストは以下の記事で可視化したMod機能でわかりました。 「Claude Modsでコンテキスト使用率とセッションコストを可視化

まずは、ローカルPC中心の環境からサーバ中心へ これまで私は、WindowsのVSCodeを中心にClaude CodeやCodexを使っていました。 コードを書くのも、調査するのも、PowerPointやWordなどのOffice資料を作るのも、 基本的には自分のPCが中心です。 これはかなり便利でした。 ただ、使っているうちに一つ気になることが出てきました。 「AIが仕事をしている間、自分のPCまで付き合わせる必要ってあるのかな？」 長めの調査や資料作成をお願いしている間は、PCを起動しておく必要があります。 PCをシャットダウンすれば、当然そこで作業も止まります。 そこで興味を持ったのが Orca でした。(単純になんか人気っぽいし利用してみたかっただけ) Orcaは、Claude CodeやCodexなど複数のAIコーディングエージェントを扱うための開発環境です。 複数のエージェントを並行して動かしたり、worktreeごとに作業を分けたりできるのが本来の使い方ですが、リモート環境で処理を動かす仕組みも用意されています。(Orcaの記事は

Claude Mods(Mod機能)がリリース(2026/10/1)されたので、セッション状態をプロンプト上に表示する簡単なModを作ってみました。 実装はClaude Codeに依頼。中身はTypeScriptです。なお、Amazon Bedrock経由で利用しているため、取得できる情報には一部制限があります。 実際の表示はこんな感じです。 【表示している情報】 ctx：コンテキスト窓の使用状況プログレスバー、使用率、トークン数の「現在値 / 上限」を表示 ses：現在のセッションにおける累計情報トークン数を input / output / cache に分けて表示 あわせてセッション累計コストも表示 表示例) ctx 24.0% 47.7k / 200.0k tokses ses 741.0k tok | in 35 | out 6.4k | cache 734.5k | cost $0.49 コンテキスト使用率が一定値を超えると、70%・90%で警告表示も出るようにしています。 長時間Claude Codeを

はじめに OPSNOTE は、インフラ作業の手順書の作成・レビュー・承認から、作業の実施、証跡の保存までをブラウザで完結させる SaaS です。AI 機能はこれまで Amazon Bedrock（東京・大阪リージョン）の Claude に集約してきました。ただ、機能を足していくうちに、文章を生成する必要はなく、「どれに当てはまるか」だけ答えてくれればよい処理がいくつも出てきました。 そこで、TypeSafe AI 社の判定専用モデル Jev を試しました。この記事では、次の 3 点をまとめます。 Jev をどの機能に、どう組み込んだか 導入前に自社データで精度をどう測ったか 効果（精度・速度・コスト）と、見送った用途 Jev とは Jev は、自由文を返さず、型の決まった質問に対して判定結果だけを返すモデルです。OPSNOTE で使った質問の型は次の 3 つです。 型 返り値 用途の例 choice 選択肢の 1 つ + confidence 「スキャナ / 実在パス / 機械経路」のどれか noul 0〜1 の確率 「このタグに該当するか」 s

はじめに — 前回までと、今回のゴール 前回（続々編）は、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エージェント、開発ツールは別物 まず、混同されやすい用語を整理します。 分類 役割 私の環境での例 開発

社内のコードとログを海外の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