2026年5月28日木曜日

ぼくの中での emacs は死んでしまったのかもしれない

ぼくの中での emacs は死んでしまったのかもしれない

さらば emacs …

結論

  • emacs は完全に AI 関連で遅れを取っている
  • Copilot や OpenAI の拡張はあるが「そうじゃない」感がすごい
  • VSCode + copilot の使い勝手に勝てない

以下詳細に綴ります

emacs 拡張を使えば各種 AI と連携はできるができるだけで公式レベルには勝てないと判断した

emacs にも copilot.el などの拡張があるので emacs から各種 AI と連携することはできます

ただ連携できるだけでエージェントや MCP 連携 (最近は MCP もほぼ使わない) がほぼ無力な印象です
ただチャットに質問しているだけで自動で編集してくれたり作成してくれたりはしません

これを執筆しているときはほぼ emacs は使っていないので何ともですが自分が copilot.el を試した時期では少なくともエージェントのような機能はありませんでした
今であれば拡張も充実してエージェント機能も充実しているかもしれませんがそれでも VSCode + copilot のエージェント機能には及ばない気がします

公式が出しているエディタに付属している公式が出しているエージェントが公式の LLM を使うという当たり前の正解

基本 AI コーディングには LLM は必須です
OpenAI や Claude、Gemini などバックエンドに専用の LLM が必要です
もちろんローカルでも OK です

すべての LLM に言えることとしてすべての LLM は挙動が違うと思っています
OpenAI だとこう答えるが Gemini だとこう答えるといういわゆる「クセ」みたいなのがあると思っています

LLM に対して質問するのは基本的にエージェントです
そのエージェントが LLM の挙動を知っているか知っていないかは AI コーディングにおいて非常に重要な点かなと思っています

例えば VScode + copilot でローカル LLM を呼び出すとしましょう
するとどうでしょうか普通に使っている copilot とは全く挙動が違って全然思い通りのコーディングをしてくれなかったなんて経験はないでしょうか
自分はかつて試したことがあり全く期待通りじゃなかったことを実感しています
もちろんローカル LLM の選択やマシンのスペックが低かったなど考えられる要因は様々あります

つまりエージェントには適した LLM があり間違った組み合わせのエージェントと LLM では AI コーディングの精度に大きな差が生まれるのです

ここまで説明すればだいたいわかると思いますが同じ公式が作ったエディタ+エージェント+LLMの組み合わせのほうが確実に良い AI コーディングができるに決まっているのです

それなのに自力でエージェントを作ってサードパーティなりローカルの LLM を呼び出し AI コーディングしてもらうのは (決して間違ってはいませんが) DRY や KISS の法則的には反しているような気が自分はしています

与えられたものを素直に使うのが良いということです

独自の AI エージェントを作る場合は別

上記の件に関して独自の AI エージェントを作る場合は別かなと思います

エージェントは自作する必要がありますし LLM もどこか選定し API をコールする必要があります
そのエージェントに何をさせるかはわかりませんが自分だけの自分専用のエージェントであれば作りましょう

だたその場合も CLI で動作するエージェントはたくさんあるのでもし自分にあった既製品があるのであればそれを使うほうが精度としては良くなることがあるかもしれません (もちろん自作のほうが良い挙動になる可能性もあります)

エージェントが賢くなりすぎて最近は MCP すらいらない気がする

かつてはエディタやエージェントから MCP にアクセスする必要がありプロセスを立ち上げていました
MCP は Ubuntu などの Linux 環境では容易に立ち上げられるし管理も用意だったのでその点では emacs との親和性はありました

しかし最近のエージェントではデフォルトでブラウザが扱えたりローカルに対してはコマンドを叩けたり外部リソースにも簡単にアクセスしたりとかつて MCP が必要だった機能をエージェントが補完してくれています (内部的に MCP をエージェントがコールしてくれているケースもありますが)

要するにエージェントが賢くなりすぎていろいろできるようになってしまったがゆえに MCP も独自で立てる必要がなくなった気がしています

もちろん MCP が不要とはいいませんが昔ほど AI コーディングにおいて MCP が必須なコンポーネントであるとは現在では思えません

RAG や他の AI プロトコルについては今回は触れませんが RAG に関しても自分は同等の意見です
また Agents.md などのコンテキストというかシステムプロンプト的なものも最近では書く必要を感じなくなりました

そうじゃない感について

自分は主に copilot を使うので比較対象が copilot になってしまうのですが copilot には「Copilot CLI」という CLI 環境で動作するエージェントもあります
それを使って emacs の拡張で足りない部分を補いことはできるかもしれませんが個人的にはそれが「そうじゃない感」を生み出している点です

開発するときには基本的にはエディタや IDE と向き合います
かつて自分が emacs で開発しているときは開発 VM に ssh しそこで tmux を立ち上げその tmux バッファないで emacs を -nw で emacs を立ち上げて開発していました

確かにその環境は素晴らしかったです
ssh して tmux バッファを開けばすでに emacs でコーディングもできるし他のバッファでアプリのビルドやテストができる状態でした
その環境自体は自分は今も好きです

ただ AI コーディングをするとなるとエディタや IDE だけで完結する必要があります (必要があるというかその方がはるかにストレスレスだと思っています)
AI に質問するのにわざわざバッファを切り替えたり AI に質問したあとでわざわざ手動でコピペするというのは今の時代だとかなりナンセンスな方法です
一昔前であればブラウザでチャッピー (ChatGPT) に質問しその結果をエディタ側にコピペしてという開発手法でしたがコンテキストの与え方を考えたりトークンの数を減らすために RAG を構築したりとかなり大変でした (それは今もやってるかもしれませんが)

AI コーディングするにあたってあっちこっち切り替えてコピペしては簡単な作業とは言えかなりストレスが溜まります
それが VSCode + copilot ではすべてその場で解決します
質問すればすべて回答しその回答結果を即時に勝手にコードに反映してくれます
もしかすると一部コピペする必要があるかもしれません
もしかすると一部のコマンドの許可を与えるためにボタンを押す必要があるかもしれません
それでもアプリを切り替えてあっちこっちいったりする必要はなく VSCode ないだけでほぼ確実に完結します

これが個人的に感じている AI コーディングにおける「そうじゃない感」です

勝っている点があるとすれば

正直ないような気もします
本当に一部のケースで(慣れの問題もありますが) emacs のほうが素早く作業できる場合はあります

  • インストール -> どちらも homebrew できる
  • CLI 環境 -> emacs は -nw、VSCode は code-server or SSH トンネルなど
  • 拡張 -> どちらもあり (elisp or JavaScript)
  • コード実行 -> どちらもあり
  • オープンソース -> どちらも
  • キーバインド -> どちらもできる

などなど emacs にしかできないことはほぼないような気がします (もちろん探せば全然ありますが表面上の利用用途としてはほぼなさそう)

それでも一部の作業はやはり emacs を使う

自分が今でも emacs を使っているケースがあります
それは単純なメモを取るときです

VSCode + copilot は何でもかんでも AI でやろうとするのでただメモを取りたいだけなのにコードサジェスチョンをしようとします
タイプ中に関係ないことをサジェスチョンされるのは嫌なのでプレーンテキストメモするときは emacs を使っています

また VSCode は基本的に 1 プロジェクトのみを開くことを対象にしているので現在開発しているプロジェクト以外を編集/閲覧したい場合には emacs を使います
一応 VSCode にも workspace という機能があり 1 つのウィンドウで複数のプロジェクトを開くことができるのですが AI のノイズになったり単純に邪魔になったりするので自分はあまり使っていません

emacs は今後も生き続けるはず

それでも emacs は今後も生き続けるはずです
emacs 自体の発展や拡張の発展が AI コーディングにより期待できるからです

先ほども記載しましたが tmux + emacs の環境は今でも好きだし使っています

またキーバインドによるショートカットや矩形選択などの編集などはまだ emacs のほうが速く作業できるケースもあるのでケースバイケースかなとも思っています
ただメインのアプリケーション開発においてはもう VSCode しか使っていません

もちろん emacs キーバインドは大好きで VSCode でも他のエディタや IDE、ターミナルソフトでも emacs キーバインドを使っています

最後に

AI エージェントが搭載されていないアプリはエディタや IDE だけではなく今後なくなってくるのかもしれません
また AI の肝はエージェントの実装と言っても過言ではないので優れたエージェントを持つアプリが生き残っていくのかもしれません

今回はその例がたまたま emacs vs VSCode だったというわけです

その他メモ

  • トラブル時にサーバに SSH ログインして作業するときも vim があれば十分なケースが多い
  • Microsoft 製のソフトウェアで唯一使っているソフトかもしれない

2026年4月5日日曜日

Switch2版ボールピットプレイメモ

Switch2版ボールピットプレイメモ

ゲームも自動化の時代

価格

  • 1360円
  • Switch2 版

とにかく進化優先

  • 進化同士を融合

建築物のアップグレードをしすぎるとヌルゲーになるかも

  • 逆に言うと建築物を優先して構築、アップグレードすると有利に進められる
  • ボス討伐後に続けられる「冒険者ギルド」の建築物を早めに作る

好きなキャラ

  • 過激派
  • 思想家
    • 全自動が楽

嫌いなキャラ

  • 影の者
    • 単純に難しい
    • 敵が手前に来られると詰む
    • 過激派にクリアしてもらう
  • 戦術家
    • 戦闘が長く面倒

好きなボール

  • レーザー系や地震などの範囲系

ゲームクリア

  • 全キャラ全建築物解放、アップグレード完了
  • ラスボスを全キャラで倒す
  • ラスボス後も無限にステージに挑戦できる
  • 既存ステージの難易度(ステージ速度)が上がる

最後に

これくらい気楽にサクっとできるゲームが好きです

2026年2月4日水曜日

軽量ローカル LLM でコーディングするのは不可能ではないがやめたほうがいい

軽量ローカル LLM でコーディングするのは不可能ではないがやめたほうがいい

不可能ではないがフラストレーションがえぐいだけ
誰でも動かせる LLM じゃあ商売上がったりなんでそりゃ無理だよねって話

結論

  • copilot レベルの精度を出すには軽量 LLM ではほぼ不可能
    • 学習および機能不足すぎる
    • 軽量 LLM では tools/thinking がない
    • 単純に学習量が少ないのか回答が的はずれななケースが多くフラストレーションが高い
  • ただしマシンスペックが潤沢 (RTX 4090/5090、メモリ VRAM+RAM が128GB 以上) なら話は別
    • 大規模 LLM が動かせれば copilot と同等の UX が得られるかも
    • 「かも」なのは実際に試せていないため

試したエディタ/エージェント環境

  • VSCode 1.108.2
  • copilot chat プラグイン (標準装備)

使ってみた LLM

  • phi4-mini:3.8b (agent)
  • llama3.1:8b (agent)
  • llama3.2:3b (ask)
  • codegemma:7b (ask)
  • gemma3:4b (ask)
  • qwen3:8b (ask)

以下それぞれ使ってみた感想です
細かい精度は違いますが大枠は変わらなかったのでモデルごとではなくまとめて記載します

感想/所感

  • thinking がないから命令を丁寧にしなければならない
    • どのコンテキストに対して何をどうやって修正すればいいのか
    • 命令の意図を解釈するフェーズが LLM にないので可能な限り丁寧に命令しなければならない
    • copilot は雑な質問でも命令を解釈しコンテキストを読み込み意図を解釈してくれる
  • Agent が使えないケースが多い
    • 使えても使い物にならない
  • 結論としては大規模 LLM が必要
    • ローカル LLM を使って copilot 相当のことをしたいのであれば大規模 LLM が必要
    • 最低でも 20b ほどだが現実ラインでは 120b レベルが必要 (gpt-oss:120b など)
    • 実際それを動かすとなると推論に必要なグラボと何よりも VRAM + RAM が必要になる
    • 120b なら合わせて 128GB ほどメモリ領域が必要になる
    • deepseek-v3.1:671b などは現実レベルでローカルで動かすのはほぼ不可能ということになる
  • 使い方が悪かった可能性もある
    • 命令やコンテキストの与え方が悪い
    • 命令が抽象的にすぎる (が本当は抽象的に質問してもやってほしい)
    • コンテキストが多すぎて LLM が解釈できない
    • 逆にコンテキストが少なすぎて無視してしまう
  • トンチンカンな回答例
    • コンテキストで与えたコードを無視して回答する
    • 単純なサンプルコードだけ提示して終了
  • 適切な LLM の設定
    • Continue などはどのフェーズでどの LLM を使用するか設定できる
    • copilot にも auto があるがローカル LLM だと使えない (はず
    • Ask/Edit/Plan で使用する LLM をカスタムエージェントで設定できるのだろうか (おそらくできない

最後に

大規模 LLM が動作するマシンが30万だとすると現在の Copilot Pro は 1500 円くらいなので

  • 300000/1500=200

で200ヶ月分は使えるので素直に Copilot Pro に課金するのがいいかもしれません
ローカルで大規模 LLM は無料と言えば無料ですが本当に無料ではありません (電気代とか)
他にゲームやマイニングとかで用途があればあってもいいかもですが

2026年1月14日水曜日

AI エージェントを作ってみた感想

AI エージェントを作ってみた感想

これまでにBotはいくつか作っていました

https://blog.kakakikikeke.com/2025/10/no-life-no-bot.html

それもエージェントと言えばエージェントなのかもしれませんがもう少しエンジニアっぽい AI エージェントを作ってみたので感想やらつらつら残しておきます

作ったもの

  • 不正プロセス監視エージェント
  • 不正ログ監視エージェント
  • 株価予測エージェント

不正プロセス監視エージェントのソースコード

#!/usr/bin/env python3
import json
import os
import subprocess
import time
from collections import deque

from google import genai
from slack_sdk import WebClient

GEMINI_API_KEY = "xxx"
SLACK_TOKEN = "xoxb-xxx"
SLACK_CHANNEL = "#general"
CUSTOM_BASE_URL = "https://your-llm-domain/endpoint"

# バッチ処理の設定
BATCH_MODE = (
    os.getenv("BATCH_MODE", "true").lower() == "true"
)  # デフォルトはバッチモード
BATCH_SIZE = int(os.getenv("BATCH_SIZE", "5"))  # 一度に判定するプロセス数
BATCH_TIMEOUT = int(os.getenv("BATCH_TIMEOUT", "10"))  # タイムアウト時間(秒)
MONITOR_INTERVAL = int(os.getenv("MONITOR_INTERVAL", "30"))  # プロセス取得間隔(秒)

print(f"Mode: {'BATCH' if BATCH_MODE else 'SINGLE'}")
print(
    f"BATCH_SIZE: {BATCH_SIZE}, BATCH_TIMEOUT: {BATCH_TIMEOUT}s, MONITOR_INTERVAL: {MONITOR_INTERVAL}s"
)

client = genai.Client(
    api_key=GEMINI_API_KEY,
    http_options=genai.types.HttpOptions(base_url=CUSTOM_BASE_URL),
)

slack = WebClient(token=SLACK_TOKEN)

# 既に通知済みのプロセスを追跡(重複通知を避けるため)
notified_processes = set()


# --- プロセス情報取得 ---
def get_processes():
    """
    ps コマンドでシステム上の全プロセスを取得する。
    戻り値: [{"pid": "...", "user": "...", "cpu": "...", "mem": "...", "cmd": "..."}, ...]
    """
    try:
        # aux フラグで詳細情報を取得
        cmd = ["ps", "aux"]
        result = subprocess.run(
            cmd,
            stdout=subprocess.PIPE,
            stderr=subprocess.PIPE,
            text=True,
            check=True,
        )

        processes = []
        lines = result.stdout.strip().split("\n")

        # ヘッダースキップ
        for line in lines[1:]:
            parts = line.split()
            if len(parts) >= 11:
                processes.append(
                    {
                        "user": parts[0],
                        "pid": parts[1],
                        "cpu": parts[2],
                        "mem": parts[3],
                        "vsz": parts[4],
                        "rss": parts[5],
                        "cmd": " ".join(parts[10:]),
                    }
                )

        return processes

    except Exception as e:
        print(f"Error getting processes: {e}")
        return []


# --- LLM にプロセスの異常判定を依頼 ---
def analyze_process_single(process_info: dict) -> bool:
    """
    単一のプロセスを LLM で判定する。
    怪しいなら True を返す。
    """
    prompt = f"""
あなたは Linux サーバーのセキュリティ監視 AI です。
以下のプロセス情報が不審かどうか、以下の形式で答えてください。

プロセス情報:
- PID: {process_info['pid']}
- ユーザー: {process_info['user']}
- CPU使用率: {process_info['cpu']}%
- メモリ使用率: {process_info['mem']}%
- VSZ: {process_info['vsz']}
- RSS: {process_info['rss']}
- コマンド: {process_info['cmd']}

判断:
- 不審なら "SUSPICIOUS"
- そうでなければ "OK"

通常のシステムプロセス(kernel threads、systemd関連など)は OK と判定してください。
考察や理由は出力しないでください。
"""

    response = client.models.generate_content(
        model="gemini-2.5-pro",
        contents=prompt,
    )

    if response.text is None:
        print("No response text from LLM")
        return False

    result_text = response.text.strip().upper()
    return "SUSPICIOUS" in result_text


def analyze_processes_batch(processes: list) -> dict:
    """
    複数のプロセスを一度に LLM で判定する。
    戻り値: {pid: bool} の辞書
    """
    if not processes:
        return {}

    # プロセス情報をまとめてプロンプト作成
    processes_text = "\n".join(
        [
            f"{i+1}. PID: {p['pid']}, User: {p['user']}, CPU: {p['cpu']}%, Mem: {p['mem']}%, Cmd: {p['cmd']}"
            for i, p in enumerate(processes)
        ]
    )

    prompt = f"""
あなたは Linux サーバーのセキュリティ監視 AI です。
以下のプロセス情報が不審かどうか、それぞれを判定してください。

プロセス一覧:
{processes_text}

判定結果を以下の JSON フォーマットで出力してください:
{{
  "1": "OK",
  "2": "SUSPICIOUS",
  "3": "OK",
  ...
}}

JSONのキーはプロセス番号、値は "SUSPICIOUS" または "OK" です。
通常のシステムプロセス(kernel threads、systemd関連など)は OK と判定してください。
"""

    response = client.models.generate_content(
        model="gemini-2.5-pro",
        contents=prompt,
    )

    if response.text is None:
        print("No response text from LLM")
        return {p["pid"]: False for p in processes}

    # JSON を抽出して解析
    result_dict = {}
    try:
        # レスポンスから JSON を抽出
        json_str = response.text
        # JSONブロックの開始と終了を探す
        start_idx = json_str.find("{")
        end_idx = json_str.rfind("}") + 1
        if start_idx >= 0 and end_idx > start_idx:
            json_str = json_str[start_idx:end_idx]
            parsed = json.loads(json_str)

            # プロセスごとに判定結果をマッピング
            for idx, process in enumerate(processes, 1):
                result = parsed.get(str(idx), "OK").upper()
                result_dict[process["pid"]] = "SUSPICIOUS" in result
        else:
            # JSON が見つからない場合は全て False
            result_dict = {p["pid"]: False for p in processes}
    except json.JSONDecodeError as e:
        print(f"JSON parse error: {e}")
        result_dict = {p["pid"]: False for p in processes}

    return result_dict


# --- Slack 通知 ---
def notify(process_info: dict):
    message = f"""
:rotating_light: *Suspicious process detected!*
PID: {process_info['pid']}
User: {process_info['user']}
CPU: {process_info['cpu']}% | Mem: {process_info['mem']}%
Command: {process_info['cmd']}
"""
    slack.chat_postMessage(channel=SLACK_CHANNEL, text=message)


# --- フィルタリング関数 ---
def should_check_process(process_info: dict) -> bool:
    """
    監視対象外のプロセスをフィルタリング
    """
    cmd = process_info["cmd"]
    user = process_info["user"]

    # self プロセスは除外
    if "process_monitor_agent" in cmd:
        return False

    # root 関連の明らかに安全なプロセスは除外
    safe_keywords = [
        "kernel",
        "[",
        "]",
        "systemd",
        "sshd",
        "agetty",
        "bash",
        "sh",
        "grep",
        "ps",
        "vim",
        "nano",
        "sudo",
        "root",
        "ls -l",
        "sd-pam",
        "unbound",
        "cron",
        "sleep",
        "less",
        "/sbin/init",
        "canonical-livepatch",
        "snapd",
        "ubuntu-advantage/timer.py",
        "multipathd",
        "journalctl",
        "bpftrace",
        # 開発ツール関連
        "tmux",
        "mysqld",
        "redis-server",
        "code-server",
        "mosquitto",
        "ollama",
        "nginx",
        # postfix 関連
        "pickup -l -t unix -u -c",
        "tlsmgr -l -t unix -u -c",
        "qmgr -l -t unix -u",
        "/usr/lib/postfix/sbin/master",
        # docker 関連
        "dockerd",
        "docker-proxy",
        # apt 関連
        "apt-get",
        "packagekitd",
        "/usr/lib/update-notifier/apt-check",
        "tar -df alternatives.tar.0 -C /var/lib/dpkg alternatives",
        # EDR 関連
        "cbram",
        "cybereason-sensor",
        "cybereason-activeconsole",
    ]
    if any(keyword in cmd for keyword in safe_keywords):
        return False

    return True


# --- プロセス監視メイン処理 ---
def monitor_processes():
    """
    定期的にプロセスを取得して監視
    """
    print("Process monitor started.")

    if BATCH_MODE:
        # バッチモード
        monitor_processes_batch()
    else:
        # 単発モード
        monitor_processes_single()


def monitor_processes_single():
    """単発モード: 各プロセスを即座に判定"""
    while True:
        try:
            processes = get_processes()

            # フィルタリング
            filtered_processes = [p for p in processes if should_check_process(p)]

            for process in filtered_processes:
                try:
                    suspicious = analyze_process_single(process)
                    if suspicious:
                        pid = process["pid"]
                        if pid not in notified_processes:
                            print(f"[!] Suspicious process: {process}")
                            notify(process)
                            notified_processes.add(pid)
                    else:
                        print(f"[OK] {process['cmd']}")

                except Exception as e:
                    print(f"Error analyzing process: {e}")

            time.sleep(MONITOR_INTERVAL)

        except Exception as e:
            print(f"Error in monitor loop: {e}")
            time.sleep(MONITOR_INTERVAL)


def monitor_processes_batch():
    """バッチモード: プロセスをバッチでまとめて判定"""
    process_buffer = deque()
    last_batch_time = time.time()

    while True:
        try:
            current_time = time.time()
            processes = get_processes()

            # フィルタリング
            filtered_processes = [p for p in processes if should_check_process(p)]

            # バッファに追加
            for process in filtered_processes:
                process_buffer.append(process)

            # バッチ処理の条件: BATCH_SIZE に達したか、BATCH_TIMEOUT を超えたか
            should_process = len(process_buffer) >= BATCH_SIZE or (
                len(process_buffer) > 0
                and current_time - last_batch_time >= BATCH_TIMEOUT
            )

            if should_process or current_time - last_batch_time >= MONITOR_INTERVAL:
                try:
                    # バッファ内のプロセスを一度に処理
                    processes_to_process = list(process_buffer)
                    process_buffer.clear()
                    last_batch_time = current_time

                    if processes_to_process:
                        results = analyze_processes_batch(processes_to_process)

                        for process in processes_to_process:
                            pid = process["pid"]
                            is_suspicious = results.get(pid, False)

                            if is_suspicious:
                                if pid not in notified_processes:
                                    print(f"[!] Suspicious process: {process}")
                                    notify(process)
                                    notified_processes.add(pid)
                            else:
                                print(f"[OK] {process['cmd']}")

                except Exception as e:
                    print(f"Error analyzing processes: {e}")

            time.sleep(1)  # CPU負荷を減らすため1秒待機

        except Exception as e:
            print(f"Fatal error: {e}")
            time.sleep(MONITOR_INTERVAL)


if __name__ == "__main__":
    while True:
        try:
            monitor_processes()
        except Exception as e:
            print(f"Fatal error: {e}, restarting in 5 seconds...")
            time.sleep(5)

これを systemd 配下で動作させています

簡単に流れの紹介

  1. ps aux の結果を取得
  2. LLM (gemini) に投げて各プロセスが怪しいか判定してもらう
  3. 怪しい場合は Slack に通知

他のログ監視も同じような仕組みです
株価予測エージェントは上記の流れとだいぶ違うのは違うのですが LLM に過去の株価情報を渡して予測してもらうだけです

感想

以下不正プロセス監視エージェントを使ってみた感想や所感です

お金がかかるので呼び出し方を工夫しなければならない

  • LLM にわたす情報を複数行にまとめて API をコールする
  • 1行ずつだと時間もかかるしお金もかかる
  • ローカル LLM が一つの解決策だがそれなりのマシンスペックは必要

判断するまでの速度

  • API (ネットワーク) + LLM の推論の時間が必ずかかるので判断までに数秒かかる
  • 完全なリアルタイムを実現するのは難しい
  • 一瞬で消えてしまうプロセスをキャッチできないケースがある
  • 速度もローカル LLM で解決できそうだが結局高スペックマシンでもそれなりの推論時間がかかるので数ミリ秒レベルのレスポンス速度は期待できない

精度が曖昧

  • 本当にアウトな場合のテストができない
  • アウトじゃないけどアウトと判定してしまう
  • アウトじゃないプロセスは無視するような仕組みが必要になる (コード内参照)
  • それ(特定のプロセス無視/ホワイトリスト形式)でいいのかという問題もある (同一プロセス名だと攻撃されても検知できなくなる)
  • 前はセーフだったけど次はアウトにしちゃう
  • 「怪しい」という LLM への命令が曖昧すぎるが故の過剰検知とハレーション

そもそもAI エージェントの具体的なユースケースは

  • 人間には難しい「判断」や「解釈」が必要なタスク+状況に応じて行動を変える仕事
  • ログから「人間レベルの洞察」を出す
  • 毎日の情報を「読む → 取捨選択 → 解釈 → 提案」する
  • インシデント予兆検知
  • コードのレポート・改善案
  • などなど、とにかく得意なのは「判断」と「解釈」あと「生成」

(現状は)何かに特化した AI エージェントしか作れない

  • 本当にやりたいことは「何でも」やってくれる汎用 AI エージェント
  • でも現状はやりたいことだけをやってくれる特化 AI エージェントしか作れない
  • もっというと「やりたいこと」すら AI エージェントが見つけて勝手にやってほしい
  • 特化エージェントを組み合わせて汎用っぽく見せかける

AI を使わなくてもいい問題

  • 今回作成した AI エージェントのようなログ監視やプロセス監視の製品はある
  • 判断が静的 (特定の文字列を含む場合にアラート/CPUが90%以上になったらなど) だがそれで十分なケースが多い

そもそも「AI エージェント」の定義は

  • 広義には「人の代わりに作業をやってくれるツール」だと思っている
  • 自分は今回のようなプロセス版のエージェントも VSCode の Copilot Chat のようなエディタもエージェントだと思っている
  • エージェントにもいろいろなタイプがあるので言葉に惑わされてはいけない

既製品を使ってもいい

ブースティング

  • 複数の LLM に判断させてその結果で最終的な判断をする
  • エヴァンゲリオンのマギシステム的なイメージ
  • ただしお金が倍々に増えていくので注意

最後に

AI もあるので AI エージェント自体を作ることは非常に簡単ですが本当に有用なものを作るのは難しいと言うか無くても何とかなるというのが正直なところです

株価予測エージェントは評価機能もあるので評価の結果が良ければ実践投入してどうなるか試してみようかなと思います
売買も自動でできると更に良いかなと思っています

2025年12月25日木曜日

2025 できたこと・できなかったこと

2025 できたこと・できなかったこと

去年に引き続き今年もやりました

できたこと

時系列

自分のプロダクトをしっかり整理できたのはよかった
すべてのプロダクトに基本的な CI がある状態になった

新規でプロダクションも追加できたのはよかった

これらもすべて AI 先生のおかげ
AI 先生の使い方もだいたいわかってきた (とりあえず質問 -> チャッピー、コーディング -> vscode + copilot chat、その他バッチなど -> API を使う)

断捨離も引き続き継続

Youtube、Podcast 活動は終わりを迎えた

その他

  • ブログ執筆数: 231 (12/24 時点)
  • Podcast エピソード数: 0

ブログの投稿数は前年度とほぼ横ばい (7記事減)
Podcast 3->0 と減少した

0 でもいいじゃない

できなかったこと

  • Youtube Live (去年に引き続き)

Youtube Live は戒め

来年の豊富

  • 引き続き断捨離 and アウトプット
  • 何か資格取る

アウトプットは全体的に多めにできたと思う
管理するアプリがまた増えたので効率的に管理できるようにしたい

ある程度の身辺整理が落ち着いたので挑戦というより安定と効率化を重視するようになった気がする

ほぼ上記は去年と同じ
やってきたことは 2024 と変わらないが更に磨きがかかった気がする

達観し始めているのかもしれない

2025年12月23日火曜日

Switch2 でダークソウルリマスタープレイメモ

Switch2 でダークソウルリマスタープレイメモ

これが死にゲーってやつか

価格

  • Switch2板 2365円

基本的な倒し方

  • 盾を構えて旋回して後ろに回って攻撃
  • スタミナに注意する
  • あとは敵のパターンを覚える(重要)
  • パリィとか後ろから致命とかは考えない
  • 初見で倒せると思わない

装備

  • 初期装備(ロングソードとハードレザー系)の強化と進化と派生で何とかなると言えばなる
  • 強化できる武器や防具のほうがおもしろい
  • ボス戦は大ダメージ武器使うと楽になるケースが多々あった
  • 自分は黒騎士の剣が序盤に取れてしまったのでそれでいった
  • クリアできないときはエスト20+軽ロリ

好きな武器

  • 黒騎士の剣

1周目クリア時ステータス

  • プレイ時間 -> 75時間
  • レベル -> 107
    • 体力40
    • 記憶力8
    • 持久力30
    • 筋力40
    • 技量30
    • 耐久力23
    • 理力9
    • 信仰9
  • 装備
    • 黒騎士の剣+5
    • 封印者シリーズ+5

強かった敵ランキング

全般的に前半の黒騎士シリーズは強すぎる印象

  1. 城下不死街 黒騎士
    • 初見で挑んで勝てるわけ無い
    • 低レベル
  2. 城下不死教区 鐘のガーゴイル
    • 二人ズルすぎ
  3. マヌス、アルトリウス、グウィン
    • タイマンだと強いと感じた2人
    • もはや何してるかよくわからない
    • 倒せないときはエスト20にしてからくればどっちも何とかなる
  4. 楔のデーモン
    • 知らんくて序盤で突っ込んでた
    • パターン覚えてからは楽
  5. はぐれデーモン
    • 衝撃波ずるすぎ
    • 衝撃波打ってこないことを祈る運ゲー
  6. 月光蝶
    • 強くはないが2回打ってくる光線が強すぎ
    • 光線を打ってこないことを祈る運ゲー

弱かった敵

  • 上記以外のボス
  • レベル上げて今日武器で適当に殴っていても勝てちゃうボスも多数
  • 中盤から強くなりすぎるとボスがだいぶ弱く感じた
  • 難しいのはダンジョン攻略になってくる

嫌いなダンジョンランキング

  1. 病み村
    • 毒うざすぎる
    • ハエみたいな敵うざすぎる
  2. 混沌の廃都イザリス
    • マグマの効果音うるさすぎ
    • マグマのせいですぐに防具が壊れる
    • 恐竜多すぎ
  3. 地下墓地
    • スケルトン無限湧き面倒すぎ
    • 滑車のやつ面倒すぎ
  4. 結晶洞窟
    • 道見えないのが意味不明

最強の敵

  • 車輪スケルトン
    • 強すぎる
  • 複数いる敵は基本強い

ソウル稼ぎ

序盤

  • 黒い森の庭
    • 紋章で入るところの篝火を使う
    • 草の敵もいて毒消し集めにもなる
    • 1周2:30で終わる
    • 坂を下って3匹の草を倒す
    • 森の広場に出て緑の鎧x2、草x4
    • 砦の前の緑の鎧x1
    • 砦近くの緑の鎧x1
    • 木に入るトカゲx1
    • で全部倒したら再度篝火に戻る

中盤/終盤

  • 黒い森の庭
    • シフの紋章のところにいるNPCを崖に落とす有名なやつ
    • 結局ここ
  • エレーミアス絵画世界
    • 真ん中に出るやりのキモいやつをまとめて倒す

アイテム稼ぎ

  • 貪欲な金の蛇の指輪+人間性を10にしてからやること

オープンワールド故の理不尽さと楽しさ

  • 小ロンド遺跡とかいきなり行けるが幽霊がいてダメージを与えれず進めないということに気づかずトライし続けてしまう
  • 自分は全くチャートがわからず普通に攻略サイトを見ながらプレイした
  • ショートカットの作成が大事
  • マップが広すぎるので覚えるのが大変

システムというか言葉も難しい

  • 亡者/生者
  • 人間性とアイテム発見率と結晶トカゲ
  • 篝火
  • 注ぎ火
  • 火防女
  • 鍛冶 (神聖,邪教,武器派生など)
  • あったかふわふわ

やりごたえはすごい

  • 周回システム
    • 2周目は強くてニューゲームだが敵も強くなっているので普通に死ねる
    • というか2周目からかなりキツくなる、敵のダメージが尋常じゃなくらい跳ね上がる
    • 脳筋レベル上げだと普通に詰むので持久力で勝負するしか無い
    • 火力も不足するので両手持ち+回避で倒せるようにするしかない部分もある
    • 周回を想定するなら魔法のほうがいいのかも
    • 7周目まで強化されるらしい
  • 縛りプレイ
  • タイムアタック

クラッシュする

  • ボス戦闘中何回かあった、頻繁という感じはしない
  • 地下墓地で車輪に引かれているとき
  • 湖獣バトル中
  • 基本背景の描画とか攻撃の描画処理が重いケースではクラッシュすることがあった

最後に

全然関係ないが Manus っていう完全自立型 AI があるらしい

2025年10月16日木曜日

ラブブを定価で買う方法

ラブブを定価で買う方法

ちゃんと正規のお店に行って買うのが一番です
一応買えたのでメモ
買い方が複雑すぎる、、

結論

  • LivePocket で抽選を受けて当選したら現地に行って購入する

お店に入るには抽選を受ける必要がある

  • ここで定期的に抽選しているのでまずはこれに応募し当選する
  • 1人1店舗しか応募できない
  • 平日の方が当選しやすいとかあるのだろうか
  • 普通にお店にいってもラブブのぬいぐるみのやつは買えない?
  • 確証はないが抽選のない通常営業日に朝から並べば買えたりするのかも (確証はない

そして抽選に当選しても買える保証がない

  • 自分はマカロンとエネジーというシリーズがほしかったが売り切れだった (しかも眼の前で
  • 購入制限はあるが売り切れることがある
  • ブラインドボックスなるガチャ箱が人気らしくそれが1人複数個買えるらしいので自分の番になる前に売り切れる可能性がある
  • 単品物(写真でいうところの紫のやつ)も人気のやつがあるらしいがこっちは比較的購入しやすそう

抽選の倍率は

  • 不明
  • とにかく抽選し続けるしかない
  • 店舗によっても変わりそう
  • 1ヶ月に1回程度なのでそもそも倍率は高くなりそう

購入制限について

  • ぬいぐるみ系は基本制限あり
  • ブラインドボックスは2種類までで個数は1ボックスに入ってる数まで
    • 例えばマカロンとエネジーでマカロン2個とエネジー3個とか
    • マカロンもエナジーもボックスは6個入っているので6個まで買えるということ
  • 単品系はそれぞれ1個まで買える
  • 事前に現在の売り切れ情報を教えてくれる
  • が自分はそうだったが入店後にエナジーが売り切れたのでこの段階で商品の在庫があるかどうか保証するものではない
  • また以下の商品が購入制限のある商品だったがこれらは店内になくレジで直接伝えて購入するのでこれらだけがほしい場合は手ぶらでレジに直行でOK
  • ただこれも説明があると思うが1人1会計のみなので店内に陳列してある商品もほしい場合はそれらを手に取ってからレジに並ばなければならない

当選番号もかなり重要

  • 自分は240番だったがその番号だと人気シリーズ(というかほしかったマカロンとエナジー)は売り切れ状態だった
  • 前にも書いたが購入制限はあるものの前の方々が上限いっぱいまで書い続ければそれだけ売り切れの可能性が増えるので若い番号のほうがいい
  • 100番内ならほぼほしいやつが買えるかもしれない
  • 当日並んだときもところどころ空き番号があったので常連は当選しても番号次第ではお目当てのものは買えないとわかっているので来ないのかもしれない

当日購入までの流れ

  • 当選したチケットの確認
  • 身分証明書を持参する
  • 当選番号で入れる時間が決まるのでその時間の確認
  • 時間の15分前に整列が始まるのでそれくらいに現地に到着すること
  • 整列
  • チケットのQRコードと身分証明書の確認
  • 購入制限の説明と現在の在庫状況の説明
  • 時間まで整列しながら待機
  • 入店
  • レジ直行
  • ほしいやつ伝えて購入
  • そく退店

という感じです
お店によりますが待機列が外の場合があるので冬は防寒対策も必須です

お店に行くとオリジナルの紙袋(40円)も購入できるのでファンには嬉しいのかも

ネットで買えるのか

  • PopMart の公式オンラインストアはある
  • がラブブ系はほぼ在庫切れ
  • 商品が入荷したら通知が来るようにできるが通知がきてすぐに行ってもほぼ売り切れ
  • 予約注文が可能になることがあるのでそのときに予約注文して届くのを待つのはあり
  • ただ箱1個とかはほぼなくボックス売りの予約注文がほぼ
  • 合計10,000万円以下の送料は660円
  • 箱1個だけの購入とかはほぼ不可能に近い印象

転売は未だに高い

  • 各種フリマサイトやショッピングサイト系を見ると未だに高い印象
  • 一時期よりかはだいぶ安くなったイメージもある?
    • エナジー定価 2,250円
    • 転売現状 5,000 - 6,000円
    • 転売少し前 10,000円

最後に

人気があるコンテンツなので仕方ないですが面倒だったので忘れないようにメモしました
入店の抽選方式は転売対策とは言えないかもですがそれでも長蛇の列を作らない、入店時のパニックなどを回避する手段としては有効かなと思いました

マカロンとエナジーは買えませんでしたがそれでも子どもたちがよろこんでくれたのでよかったです

昔のハイパーヨーヨーとかたまごっちみたいな一時的に爆発的に人気になるコンテンツは今も昔も変わらずあるんだろうなと感じた、、