2026年7月20日月曜日

ローカルLLMでコーディングさせるポイント

 簡単な指示で、依頼するとコンテキストオーバーで記憶喪失になって

コードの内容が一致しないことが起こるので、work.mdみたいな作業メモを取らせたるのがよい

途中から、別スレッドに再実施する場合でも、work.mdが引き継ぎとして

参照して実施してくれるのがポイント



時刻: 0 件のコメント:
ラベル:

2026年7月19日日曜日

Kubernetes運用でHermes MCPを試してみた感想 ― k9s代替としての可能性とGitOpsとの役割分担

 最近、Kubernetes環境の運用にAIエージェントを組み込む試みをしています。

今回試したのは、MCP（Model Context Protocol）経由でKubernetesを操作できるHermes Agentです。

最初は「AIにKubernetesマニフェストを書かせて、そのままデプロイまで全部やらせれば便利なのでは？」という考えで試してみました。

しかし、実際に触ってみると、得意な領域と苦手な領域がかなり明確に分かれました。

結論から言うと、Hermes MCPは Kubernetesの作成ツールというより、k9sやkubectlのAI版として使うほうが相性が良い と感じました。

Kubernetes環境

今回の検証環境は、Raspberry PiベースのKubernetesクラスタです。

構成は以下のようなものです。

  • control-plane: rasp-master

  • worker: rasp-node1

  • worker: rasp-node2

  • Kubernetes version: v1.35.1

小規模ながら、Deployment、Service、StatefulSet、Ingressなどを使った一般的なアプリケーション構成を試しています。

対象アプリケーションは stock-app というサンプルアプリで、

  • stock-api

  • stock-ui

  • PostgreSQL

  • Ingress

という構成にしました。

最初はAIにマニフェスト作成から任せてみた

最初に考えたのは、

「AIエージェントにKubernetes YAMLを書かせて、そのままクラスタへ適用できるのでは？」

という使い方でした。

実際、Ingress YAMLの作成などは非常にスムーズでした。

例えば、

  • ingress-nginx Controllerの確認

  • IngressClass確認

  • rewrite設定

  • backend Serviceとの接続設定

などは自然言語で指示できます。

また、

「推測禁止。kubectl結果のみ報告」

という形で指示すると、余計な説明を減らして実際の状態確認に集中できます。

これはかなり便利でした。

しかし、ファイル操作とGit操作で問題が発生

一方で、マニフェストを作成してGitHubへpushする段階で、少し混乱が発生しました。

原因は、AIエージェントが扱う環境が複数存在することです。

例えば、

  • AIが書き込むファイル環境

  • MCP経由のファイル環境

  • kubectlを実行する環境

  • ローカルGit環境

は、人間から見ると同じパスに見えても、実際には別環境になる場合があります。

実際に、

/tmp/stock-app.yaml

を作成したつもりでも、

別の実行環境から見ると、

file not found

になるという現象が発生しました。

人間がターミナルを複数開いている時に起こる「別環境を見ている」問題と同じです。

GitOpsとの相性を考える

今回の経験から、Kubernetesでは役割分担したほうが良いと感じました。

理想的には：

開発
 ↓
VS Code / OpenCode / AI Coding Agent
 ↓
GitHub
 ↓
Argo CD
 ↓
Kubernetes
 ↓
Hermes MCP

という流れです。

つまり、

マニフェストを書く場所はGitリポジトリ。

クラスタへ反映するのはArgo CD。

状態確認や障害調査はHermes MCP。

という分担です。

Hermes MCPはk9sの代替になるか？

個人的には、完全な置き換えというより、

「AIを搭載したk9s」

という位置付けが近いと思います。

k9sの場合：

  • Pod一覧を見る

  • Logを見る

  • Describeする

  • Namespaceを移動する

  • Resource状態を見る

という操作を自分で行います。

Hermesの場合は、

「stock-appのPodが落ちている原因を調べて」

というように、目的を伝えられます。

するとAIが、

  • Pod確認

  • Event確認

  • Service確認

  • Deployment確認

という調査手順を踏んでくれます。

Kubernetes初心者向けというより、むしろ運用経験者が調査速度を上げる用途に向いていると感じました。

作成は人間、運用はAIという分担

今回の検証で一番感じたのは、

「AIに全部任せる」

より、

「AIが得意な部分に任せる」

ほうが良いということです。

マニフェスト作成やGit管理は、

  • 差分確認

  • ファイル構成確認

  • commit履歴

が重要なので、人間が見える環境で行うほうが安心です。

一方でKubernetes運用は、

  • 状態確認

  • 原因調査

  • リソース探索

が中心なので、AIとの相性が非常に良いです。

まとめ

Hermes MCPを試した結果、個人的な評価は以下です。

得意

  • Kubernetes状態確認

  • kubectl操作補助

  • 障害調査

  • Resource関連調査

  • k9s的な利用

苦手

  • 複雑なファイル生成

  • Gitリポジトリ管理

  • 複数環境をまたぐファイル操作

Kubernetesでは今後、

「GitOpsで宣言的管理」
+
「AIエージェントによる運用支援」

という組み合わせが現実的だと思います。

Hermes MCPは、Kubernetesを操作するための新しいインターフェースとして、k9sやkubectlを補完する存在になりそうです。


<Hermes Agent MCP設定確認>

Hermes Agentでは、MCP（Model Context Protocol）の設定を ~/.hermes/config.yaml に記載します。

設定ファイルの場所：

~/.hermes/config.yaml

設定内容を確認する場合：

cat ~/.hermes/config.yaml

または MCP設定部分のみ確認：

grep -A20 mcp_servers ~/.hermes/config.yaml

Kubernetes MCP連携の設定例：

mcp_servers:
  kubernetes:
    command: "xxxxx"
    args:
      - "xxxxx"

command と args には、利用するMCP Serverの実際の起動コマンドを指定します。

Hermes Agentでは、このMCP設定を追加することで、AI Agentから外部ツール（今回の場合はKubernetes）へアクセスできるようになります。

時刻: 0 件のコメント:
ラベル:

2026年7月11日土曜日

EXOでMacStudioをクラスタリング

以下のMacStudio2台に、EXOを使ってクラスタリングを行います。

①MacStudio(M1 MAX 32GB)

②MacStudio(M4 MAX 36GB)


1)導入方法は、以下を参照。

参照先：https://github.com/exo-explore/exo/releases


2)thunderboltケーブルで、お互いのMacStudioに接続します。







3)以下のEXO用のLLMをダウンロード












4)EXOにて、2台のMacStudioの接続状況が確認できる








































LLMを導入後、Mac間で連携ができていることが
以下の画面上から確認できた。




















最後に、メッセージを送信してみる


































試しに、RooCodeとHermes agent desktopでEXOの連動を試してみたが
上手くいかなかった。


次にOpenCodeで実施してみると、EXOと連動できた
LLMは、Qwen3.6-35B-A3B-4bit

<OpenDesktopの画面>





































実行中のステータス表示


時刻: 0 件のコメント:
ラベル:

2026年6月14日日曜日

各AIツールの検証結果とリアルな評価：私感

 MacStudio M4 MAX 36GB/1TBを使っていて
個人的な、Aiエージェントの検証結果になります。
各エージェントのパラメータの意味や模索で結構時間が溶けてしまった。。。


各AIツールの検証結果とリアルな評価

ツール名評価とリアルなボトルネック
Roo Code (Roo Cline)非常に賢いが、自律駆動のループによるメモリ大食い＆スワップ多発でメインマシンの快適性を損なう。
Hermes Agent賢さは申し分ないが、こちらもメモリ消費が激しくスワップを誘発するため常用は厳しい。
Hermes Agent Desktop期待大だが、現時点ではまだアルファ版かつ日本語非対応で実用段階に一歩届かず。
Continue動作自体は非常に軽量だが、UI/UXを含めた使い勝手が肌に合わない。
Cursor本質的に「なんちゃってVS Code（フォーク版）」であり、将来的な有料化の気配やベンダーロックインを考えると、あえて乗り換えるメリットが薄い。
AiderCLI（CUI）単体で完結させるならアリだが、VS Code版プラグインで llama.cpp が直叩きできないのが致命的。
OpenCodeVS Codeとシームレスに調和し、llama.cpp の軽快さをそのまま活かせる「良い塩梅」の着地点。

時刻: 0 件のコメント:

VS code(plugin: open code)

 VsCodeで、リソースが食わない
Aiエージェントのプラグインを探していたが
OpenCodeが結構いいかもって思ったので投稿してみました。













Roo codeは、賢いがリソースがメチャクチャ食うし
contiuneは、軽量だが使い勝手が悪すぎるので、良いのが見つからなかったが
OpenCodeをVsCodeで動かすスタンスが、現状、良い塩梅かもしれない。

あと、AiderのVsCodeのプラグイン版もあるけど、llama cpp経由で使えないので
理想とは異なっていた。



時刻: 0 件のコメント:

AIエージェントの模索してみました編

様々な、AIエージェントの模索をしてきました。
（時間を相当溶かしました。。）

私なりの現在の結果です。


Roo Code------------------>賢こかったが、スワップ発生がNG
hermes agent -------------->賢いがメモリー食う
continue-------------------->使い勝手がくそすぎる
Aider------------------------>悪くないが、vs codeライクがいいなっとぼやく
Aider chat------------------>vs codeのプラグインでだが、llama cppに対応してないくそが
Opencode------------------->aiderと同様
Cusur----------------------->別にvs codeでいいじゃない説がでてきた
Hermes agent desktop --->日本語に対応してない（発展途上なんで仕方がないが。。）


Mac Studio M4 MAX 36GB/1TBでの結果でした。

時刻: 0 件のコメント:

2026年5月6日水曜日

AIツール断捨離の果てに

 

導入

  • ハード環境: Mac Studio M4 Maxの導入。

  • 背景: 以前から使い倒してきたITエンジニアとして、話題のAIツール（Cursor, Zed, Void, Continue, Roo Codeなど）を片っ端から実戦投入してみたこと。

  • 目的: ツールをいじる時間は最小限に。本来の「達成感」を得るための開発環境を整えること。

1. 期待したが「断捨離」したものとその理由

  • Roo Code: 推論ステップが多く、M4 Maxのファンが回るほど考え込んでしまう。「思考の待ち時間」がネックに。

  • Zed (OSS): 動作は爆速だが、日本語入力に癖があり、指示を中国語で返してくるなどの不安定さが致命的。

  • Void: 設定の煩雑さや日本語の取り回しの不自然さが、30年の指先には合わなかった。

2. 生き残った「一軍」の二枚看板

① Cursor（メイン・司令塔）

  • 選定理由: 日本語がスムーズに通る。指示から「Plan」提示までの到達が圧倒的に早く、terraform init などの実行まで任せられる「話の通じる」相棒。

  • 使い方: 構造の大きな変更や、プロジェクト全体を把握させたい時。

② OpenCode Zen（ミニマル・OSS）

  • 選定理由: 広告などのノイズが一切ない。画像（スクリーンショット）の通り、これ以上ないほどシンプルな「書く」ための究極の空間。

  • 使い方: 自分のロジックに集中したい時や、AIに頼りすぎずクリーンにコードを書きたい時。

時刻: 0 件のコメント:
ラベル:

「エディタ統合型」か「CLI/エージェント型」か、そして「操作性（UX）」の観点で整理



1. Cursor：圧倒的なUXを誇るIDE統合型

VS Codeをフォークして作られた独自のIDEです。

  • 特徴: コードベース全体のインデックス作成能力が非常に高く、プロジェクト全体を俯瞰した修正が得意。

  • 強み: 導入が簡単で、チャットや補完のレスポンスが極めてスムーズ。

  • ブログの切り口: 「とりあえずこれを選べば間違いない」という、完成度No.1ツールとしての紹介。

2. OpenCode (OpenCodeInterpreter)：実行と修正を繰り返す「知能」

特定のツールというより、コードの「生成・実行・フィードバック・修正」のサイクルを回すために最適化されたオープンなモデル/システムを指します。

  • 特徴: 従来のLLMと異なり、コードを書くだけでなく、実際に動かしてエラーが出たら自ら直す「自己反復」の能力に特化。

  • 強み: オープンソースであり、特定のベンダーに依存せずに高度なコード推論が可能。

  • ブログの切り口: 「ただのチャットではなく、実行結果を見て改善する」次世代の知能としての紹介。

3. aider：ターミナルで爆走するCLIエージェント

コマンドライン上でLLMと対話しながら、既存のファイルを直接編集させるツールです。

  • 特徴: gitとの強力な連携機能。編集が終わると、変更内容を説明するコミットメッセージと共に自動でコミットまで完了します。

  • 強み: エディタを選ばず、ターミナル操作に慣れたエンジニアにとっての作業スピードが劇的に速い。

  • ブログの切り口: 「VimやVS Codeなど、自分の好きなエディタと組み合わせて使える爆速ツール」としての紹介。

4. Roo Code (Roo Cline)：MCP対応の自律型エージェント

VS Codeの拡張機能として動作し、AIに「コンピュータの操作権限」を渡してタスクを完遂させるツールです。

  • 特徴: ファイル作成、コマンド実行、ブラウザ操作などをAIが自律的に行います。MCP（Model Context Protocol）に対応し、外部ツールとの連携が容易。

  • 強み: 「テストが通るまでバグを直して」といった丸投げの指示を実現可能。

  • ブログの切り口: 「AIを単なるアシスタントから、自律的な部下へと変えるツール」としての紹介。

5. Continue：カスタマイズ自由自在なオープン・ハブ

VS CodeやJetBrainsに対応した、オープンソースの拡張機能です。

  • 特徴: 任意のLLM（APIやローカルのOllamaなど）を自由に組み合わせて利用できる。

  • 強み: 特定の商用サービスに縛られず、プライバシーを重視したローカル完結型の環境を構築しやすい。

時刻: 0 件のコメント:

2026年5月5日火曜日

SwiftBarで構築するLLM（llama-server）のワンクリック起動環境

 

1. 実装のゴール

M4 Maxのパワーを活かし、ローカルLLM環境（llama.cpp）をターミナルなしで制御することを目指します。

  • メニューバーにステータス（起動中/停止中）を表示。

  • ワンクリックで llama-server を起動・停止。

  • SwiftBarの仕様に基づき、エラー（はてなマーク）を徹底排除する。

2. 起動・制御用シェルスクリプト

今回作成した llama_control.1s.sh の全容です。

--------------Bash-------------------
#!/bin/bash

# --- 環境設定 ---
# GUIアプリから呼ばれるため、PATHを明示してコマンドを見失わないようにする
export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"

# パス設定（各自の環境に合わせて変更）
MODEL_PATH="/Users/hidenari/models/Qwen3.5-9B-Q8_0.gguf"
LOG_FILE="/tmp/llama.log"
# SwiftBarに無視させるため、PIDファイルはドット（.）で始めるのがコツ
PID_FILE="/Users/hidenari/Documents/SwiftBar/.llama-server.pid"
# 自分自身のフルパス（SwiftBarの再帰呼び出しを確実にするため）
SELF_PATH="/Users/hidenari/Documents/SwiftBar/llama_control.1s.sh"

# --- プロセスチェック ---
# pgrepでプロセスを直接確認。名前で狙い撃ち
CURRENT_PID=$(pgrep -f "llama-server.*Qwen3.5-9B")

if [ -n "$CURRENT_PID" ]; then
    STATUS="Running"
    COLOR="green"
    ICON="🤖"
else
    STATUS="Stopped"
    COLOR="red"
    ICON="💤"
fi

# --- SwiftBarへの出力 ---
# メニューバーの表示
echo "$ICON LLM: $STATUS | color=$COLOR"
echo "---"

if [ "$STATUS" = "Stopped" ]; then
    # 起動コマンド：ターミナルを開かずバックグラウンドで実行
    echo "Launch Qwen 3.5 | bash='$SELF_PATH' param1=start terminal=false"
else
    # 停止コマンド
    echo "Stop llama-server | bash='$SELF_PATH' param1=stop terminal=false"
    echo "PID: $CURRENT_PID"
fi

# --- 実行ロジック（SwiftBarからの引数 $1 で分岐） ---
case "$1" in
    start)
        if [ -z "$CURRENT_PID" ]; then
            cd /Users/hidenari/llama.cpp/build/bin/
            # M4 Maxの性能をフル活用（GPU全レイヤー、Flash Attention有効）
            nohup ./llama-server -m "$MODEL_PATH" -c 65536 --n-gpu-layers 99 --port 8080 --flash-attn on > "$LOG_FILE" 2>&1 &
            sleep 2
        fi
        ;;
    stop)
        # 確実にプロセスを終了させる
        TARGET_PID=$(pgrep -f "llama-server.*Qwen3.5-9B")
        [ -n "$TARGET_PID" ] && kill -9 $TARGET_PID
        ;;
esac

---------------------------------------------------

3. こだわりの「記載過程」とエンジニアの知恵

① 「はてなマーク」との決別：隠しファイルの活用

SwiftBarはディレクトリ内の全ファイルを自動実行しようとします。以前、プロセスIDを保存する llama-server.pidを置いていたところ、SwiftBarがそれを「スクリプト」と勘違いして実行しようとし、エラー（はてなマーク）が発生しました。

  • 対策: ファイル名を .llama-server.pid とドットから始まる隠しファイルに。SwiftBarはこのファイルを無視するため、メニューバーがクリーンに保たれます。

② 「自分自身」をフルパスで定義する

GUIアプリであるSwiftBarから呼び出される際、相対パス（$0）は不安定になりがちです。

  • 対策: SELF_PATH 変数にスクリプトのフルパスを直接記載。これにより、メニューからクリックした際のコマンド実行ミスをゼロにしました。

③ M4 Maxのポテンシャルを活かす

起動パラメータに --n-gpu-layers 99 と --flash-attn on を指定。

  • これにより、Qwen 3.5クラスのモデルも爆速で動作。ハードの性能を最大限引き出すのがインフラエンジニアの醍醐味です。

時刻: 0 件のコメント:
ラベル: ,

M4 Maxをさらに快適に。SwiftBarでLLM（llama-server）とメモリ解放をメニューバーから一元管理する

 

1. はじめに

  • 動機: M4 Max搭載Mac Studioという強力なインフラを最大限活かすため、ローカルLLM（Qwen 3.5など）の起動・停止や、purge コマンドによるメモリリフレッシュをGUI（メニューバー）から行えるようにしたかった。

  • 使用ツール: SwiftBar（Macのメニューバーにスクリプトの結果を表示し、操作を可能にするオープンソースアプリ）

2. SwiftBarの導入

  • インストール: SwiftBar公式サイト または brew install --cask swiftbar で導入。

  • プラグインディレクトリの設定: スクリプトを保存するための専用ディレクトリ（例: ~/Documents/SwiftBar）を作成し、SwiftBarに指定する。

3. メモリ解放（purge）の自動化

sudo 権限が必要な purge コマンドを、パスワード入力なしでメニューバーから実行するための設定。

  • visudoの設定: セキュリティを保ちつつ、特定のコマンドだけパスワードなしで実行できるようにする。

    -------------Bash----------------------------------
    # sudo visudo で末尾に追記
hidenari[User名] ALL=(ALL) NOPASSWD: /usr/sbin/purge

    ---------------------------------------------

  • スクリプトの作成 (purge_memory.1m.sh):

    • 1m という名前をつけることで1分ごとに更新。

    • 実行時の標準エラー出力を > /dev/null 2>&1 で捨てるのが、SwiftBarに「はてなマーク（エラー）」を出させないコツ。

4. ローカルLLM（llama-server）の管理

LLMのステータス（Running/Stopped）を監視し、ワンクリックで起動・停止するスクリプト。

  • ポイント1：PIDファイルの隠しファイル化: SwiftBarはディレクトリ内の全ファイルを実行しようとするため、PIDファイル（.llama-server.pid）の先頭にドットを付けて無視させる。これで「はてなマーク」の発生を防ぐ。

  • ポイント2：フルパスの指定: GUIアプリであるSwiftBarから実行する場合、環境変数や相対パス（$0）が不安定になるため、スクリプト内で SELF_PATH を定義し、絶対パスで自分自身を呼び出すように設計。

5. トラブルシューティング：なぜ「はてなマーク」が出るのか？

エンジニアとしてハマりやすいポイントの解説。

  • 原因: SwiftBarがスクリプトではないファイル（PIDファイルやバックアップファイル）を読み込もうとしてエラーを吐く。

  • 対策: ディレクトリ内の不要なファイルを削除（rm llama-server.pid）し、一時ファイルは必ずドットから始まる名前にする。

6. まとめ

  • M4 Maxの広大なメモリを、指先ひとつでいつでもリフレッシュできる最強の環境が完成。

  • シェルスクリプトという「古くて新しい道具」を、SwiftBarのような現代のツールと組み合わせる楽しさ。

時刻: 0 件のコメント:
ラベル:

2026年5月4日月曜日

Mac Studio で作る完全ローカル AI 開発環境（OpenCode + Qwen 3.5）

 

1. はじめに

  • 背景: クラウド AI（OpenAI 等）にコードを投げたくない、あるいは API コストを抑えたい。

  • 解決策: Apple Silicon (UMA) のパワーを活かし、OpenCode と llama-server でローカル完結のエージェント環境を構築する。

2. 事前準備：Llama-server の起動

秀成さんが実行したコマンドをベースに、GPU をフル活用する設定を紹介します。

Bash
# Llama-server の起動例
llama-server \
  --model ~/models/Qwen3.5-9B-Q8_0.gguf \
  --ctx-size 8192 \
  --port 8080 \
  --ngl 99

  • ポイント: --ngl 99 で全てのレイヤーを GPU (Metal) にオフロードし、爆速化する。

3. OpenCode のインストールと「魔の」設定ファイル

ここが一番のハイライトです。UI から設定しても反映されない場合の「正解の JSON 構造」を記載します。

  • 設定パス: ~/.config/opencode/config.json

  • 正解の書き方:

JSON
{
  "provider": {
    "openai": {
      "apiKey": "dummy",
      "baseUrl": "http://localhost:8080/v1"
    }
  },
  "model": "local"
}

  • 注意点: providers（複数形）ではなく provider であること、model キーの階層が外側であることを強調します。

4. 実際の動作：Terraform 等での検証

秀成さんが成功した "Screenshot 2026-05-04 at 23.28.36.jpg" のような、具体的なコード生成例を載せます。

  • 「つぎに sg と vps を作成して」といった曖昧な指示から、プロバイダー設定を含む main.tf が一瞬で生成される様子を紹介。

5. Automator による「一発起動アプリ」化

ターミナルを叩く手間を省くための、エンジニアらしい自動化ハックを紹介します。

  • llama-server と opencode を同時に立ち上げるスクリプトの解説。




時刻: 0 件のコメント:
ラベル:
登録: 投稿 (Atom)

ローカルLLMでコーディングさせるポイント

 簡単な指示で、依頼するとコンテキストオーバーで記憶喪失になって コードの内容が一致しないことが起こるので、work.mdみたいな作業メモを取らせたるのがよい 途中から、別スレッドに再実施する場合でも、work.mdが引き継ぎとして 参照して実施してくれるのがポイント