flower road: 7月 2026

2026年7月20日月曜日

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

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

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

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

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

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）へアクセスできるようになります。

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の画面>

実行中のステータス表示

登録: 投稿 (Atom)