様々な、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での結果でした。
ハード環境: Mac Studio M4 Maxの導入。
背景: 以前から使い倒してきたITエンジニアとして、話題のAIツール（Cursor, Zed, Void, Continue, Roo Codeなど）を片っ端から実戦投入してみたこと。
目的: ツールをいじる時間は最小限に。本来の「達成感」を得るための開発環境を整えること。
Roo Code: 推論ステップが多く、M4 Maxのファンが回るほど考え込んでしまう。「思考の待ち時間」がネックに。
Zed (OSS): 動作は爆速だが、日本語入力に癖があり、指示を中国語で返してくるなどの不安定さが致命的。
Void: 設定の煩雑さや日本語の取り回しの不自然さが、30年の指先には合わなかった。
選定理由: 日本語がスムーズに通る。指示から「Plan」提示までの到達が圧倒的に早く、terraform init などの実行まで任せられる「話の通じる」相棒。
使い方: 構造の大きな変更や、プロジェクト全体を把握させたい時。
選定理由: 広告などのノイズが一切ない。画像（スクリーンショット）の通り、これ以上ないほどシンプルな「書く」ための究極の空間。
使い方: 自分のロジックに集中したい時や、AIに頼りすぎずクリーンにコードを書きたい時。
VS Codeをフォークして作られた独自のIDEです。
特徴: コードベース全体のインデックス作成能力が非常に高く、プロジェクト全体を俯瞰した修正が得意。
強み: 導入が簡単で、チャットや補完のレスポンスが極めてスムーズ。
ブログの切り口: 「とりあえずこれを選べば間違いない」という、完成度No.1ツールとしての紹介。
特定のツールというより、コードの「生成・実行・フィードバック・修正」のサイクルを回すために最適化されたオープンなモデル/システムを指します。
特徴: 従来のLLMと異なり、コードを書くだけでなく、実際に動かしてエラーが出たら自ら直す「自己反復」の能力に特化。
強み: オープンソースであり、特定のベンダーに依存せずに高度なコード推論が可能。
ブログの切り口: 「ただのチャットではなく、実行結果を見て改善する」次世代の知能としての紹介。
コマンドライン上でLLMと対話しながら、既存のファイルを直接編集させるツールです。
特徴: gitとの強力な連携機能。編集が終わると、変更内容を説明するコミットメッセージと共に自動でコミットまで完了します。
強み: エディタを選ばず、ターミナル操作に慣れたエンジニアにとっての作業スピードが劇的に速い。
ブログの切り口: 「VimやVS Codeなど、自分の好きなエディタと組み合わせて使える爆速ツール」としての紹介。
VS Codeの拡張機能として動作し、AIに「コンピュータの操作権限」を渡してタスクを完遂させるツールです。
特徴: ファイル作成、コマンド実行、ブラウザ操作などをAIが自律的に行います。MCP（Model Context Protocol）に対応し、外部ツールとの連携が容易。
強み: 「テストが通るまでバグを直して」といった丸投げの指示を実現可能。
ブログの切り口: 「AIを単なるアシスタントから、自律的な部下へと変えるツール」としての紹介。
VS CodeやJetBrainsに対応した、オープンソースの拡張機能です。
特徴: 任意のLLM（APIやローカルのOllamaなど）を自由に組み合わせて利用できる。
強み: 特定の商用サービスに縛られず、プライバシーを重視したローカル完結型の環境を構築しやすい。
M4 Maxのパワーを活かし、ローカルLLM環境（llama.cpp）をターミナルなしで制御することを目指します。
メニューバーにステータス（起動中/停止中）を表示。
ワンクリックで llama-server を起動・停止。
SwiftBarの仕様に基づき、エラー（はてなマーク）を徹底排除する。
今回作成した llama_control.1s.sh の全容です。
#!/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
---------------------------------------------------SwiftBarはディレクトリ内の全ファイルを自動実行しようとします。以前、プロセスIDを保存する llama-server.pidを置いていたところ、SwiftBarがそれを「スクリプト」と勘違いして実行しようとし、エラー（はてなマーク）が発生しました。
対策: ファイル名を .llama-server.pid とドットから始まる隠しファイルに。SwiftBarはこのファイルを無視するため、メニューバーがクリーンに保たれます。
GUIアプリであるSwiftBarから呼び出される際、相対パス（$0）は不安定になりがちです。
対策: SELF_PATH 変数にスクリプトのフルパスを直接記載。これにより、メニューからクリックした際のコマンド実行ミスをゼロにしました。
起動パラメータに --n-gpu-layers 99 と --flash-attn on を指定。
これにより、Qwen 3.5クラスのモデルも爆速で動作。ハードの性能を最大限引き出すのがインフラエンジニアの醍醐味です。
動機: M4 Max搭載Mac Studioという強力なインフラを最大限活かすため、ローカルLLM（Qwen 3.5など）の起動・停止や、purge コマンドによるメモリリフレッシュをGUI（メニューバー）から行えるようにしたかった。
使用ツール: SwiftBar（Macのメニューバーにスクリプトの結果を表示し、操作を可能にするオープンソースアプリ）
インストール: brew install --cask swiftbar で導入。
プラグインディレクトリの設定: スクリプトを保存するための専用ディレクトリ（例: ~/Documents/SwiftBar）を作成し、SwiftBarに指定する。
sudo 権限が必要な purge コマンドを、パスワード入力なしでメニューバーから実行するための設定。
visudoの設定: セキュリティを保ちつつ、特定のコマンドだけパスワードなしで実行できるようにする。
# sudo visudo で末尾に追記
hidenari[User名] ALL=(ALL) NOPASSWD: /usr/sbin/purge
---------------------------------------------スクリプトの作成 (purge_memory.1m.sh):
1m という名前をつけることで1分ごとに更新。
実行時の標準エラー出力を > /dev/null 2>&1 で捨てるのが、SwiftBarに「はてなマーク（エラー）」を出させないコツ。
LLMのステータス（Running/Stopped）を監視し、ワンクリックで起動・停止するスクリプト。
ポイント1：PIDファイルの隠しファイル化: SwiftBarはディレクトリ内の全ファイルを実行しようとするため、PIDファイル（.llama-server.pid）の先頭にドットを付けて無視させる。これで「はてなマーク」の発生を防ぐ。
ポイント2：フルパスの指定: GUIアプリであるSwiftBarから実行する場合、環境変数や相対パス（$0）が不安定になるため、スクリプト内で SELF_PATH を定義し、絶対パスで自分自身を呼び出すように設計。
エンジニアとしてハマりやすいポイントの解説。
原因: SwiftBarがスクリプトではないファイル（PIDファイルやバックアップファイル）を読み込もうとしてエラーを吐く。
対策: ディレクトリ内の不要なファイルを削除（rm llama-server.pid）し、一時ファイルは必ずドットから始まる名前にする。
M4 Maxの広大なメモリを、指先ひとつでいつでもリフレッシュできる最強の環境が完成。
シェルスクリプトという「古くて新しい道具」を、SwiftBarのような現代のツールと組み合わせる楽しさ。
背景: クラウド AI（OpenAI 等）にコードを投げたくない、あるいは API コストを抑えたい。
解決策: Apple Silicon (UMA) のパワーを活かし、OpenCode と llama-server でローカル完結のエージェント環境を構築する。
秀成さんが実行したコマンドをベースに、GPU をフル活用する設定を紹介します。
# Llama-server の起動例
llama-server \
--model ~/models/Qwen3.5-9B-Q8_0.gguf \
--ctx-size 8192 \
--port 8080 \
--ngl 99
ポイント: --ngl 99 で全てのレイヤーを GPU (Metal) にオフロードし、爆速化する。
ここが一番のハイライトです。UI から設定しても反映されない場合の「正解の JSON 構造」を記載します。
設定パス: ~/.config/opencode/config.json
正解の書き方:
{
"provider": {
"openai": {
"apiKey": "dummy",
"baseUrl": "http://localhost:8080/v1"
}
},
"model": "local"
}
注意点: providers（複数形）ではなく provider であること、model キーの階層が外側であることを強調します。
秀成さんが成功した "Screenshot 2026-05-04 at 23.28.36.jpg" のような、具体的なコード生成例を載せます。
「つぎに sg と vps を作成して」といった曖昧な指示から、プロバイダー設定を含む main.tf が一瞬で生成される様子を紹介。
ターミナルを叩く手間を省くための、エンジニアらしい自動化ハックを紹介します。
llama-server と opencode を同時に立ち上げるスクリプトの解説。
私が構築したのは、役割を明確に分担させた多段構成だ。
1層目（実装担当）：ローカルAI (Qwen3-9B / Roo Code)
実行環境: M4 Max / M1 Max (llama.cpp)
役割: ジュニアエンジニア。Terraformやスクリプトの初稿を爆速で書き上げる。
利点: APIコストを気にせず、機密情報を外に出さずに「100回の試行錯誤」ができる。
2層目（査読担当）：クラウドAI (Google Code Assist / GitHub Copilot)
役割: シニアエンジニア。
内容: ローカルAIが吐き出したコードのバグ、セキュリティ、ベストプラクティスをチェックし、洗練させる。
利点: クラウド側の膨大な計算資源と、最新のドキュメントに基づいた「大局的な判断」を仰ぐ。
3層目（承認担当）：自分自身
役割: CTO / 最終意思決定。
内容: 30年の経験をもとに、AIたちの提案が「現場の運用」に耐えうるかを判断する。
ローカルで動かす9Bクラスのモデルは、タイピングや定型コードの生成には非常に長けているが、全体像を把握する能力には限界がある。
一方、クラウドAI（特にGemini Code Assistなど）はコンテキスト窓が広く、プロジェクト全体を俯瞰したレビューができる。 「下書きは若手（ローカル）に、ハンコを貰う前の添削はベテラン（クラウド）に」 この役割分担が、個人の開発効率を極限まで引き上げる。
これまでGitHub Copilot Proに月10ドル払ってきたが、この構成が完成してから「いらないかもしれない」と考え始めた。 Google Code Assistの強力な無料枠があるうちは、クラウドAIを「無料のシニア」として活用し、余った予算はデバイスや投資（恩株など）に回すのが賢明だ。
もし将来的にクラウドAIが高価になる「災厄」が来ても、この構成なら問題ない。 「ローカルAI（実装）→ 自分（レビュー・承認）」 のセミオート構成に切り替えるだけだ。自前のM4 Max環境と、30年のキャリアがあれば、AIの価格変動に振り回されることはない。
エンジニアとしての達成感は、常に道具を最適化し、自らの手で環境を支配することにある。 M4 MaxのパワーをLLMに振り向け、クラウドを賢く使い倒す。これが、2026年現在の私の最適解だ。
コマンドを叩いてサーバーを立てるのも一興だが、真の「達成感」は、Macを立ち上げた瞬間にすべての環境が整っている「透明な自動化」にある。
macOS標準のサービス管理システム launchd を使い、ログインした瞬間に M1 Max（リモート）と M4 Max（ローカル）の AI サーバーをバックグラウンドで目覚めさせる設定を組んだ。
まずはメイン機 M4 Max 自身で、爆速の qwen3.5-9b を立ち上げる設定だ。
ファイルパス: ~/Library/LaunchAgents/com.hidenari.qwen35.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.hidenari.qwen35</string>
<key>ProgramArguments</key>
<array>
<!-- 1. 実行ファイルの場所を特定したフルパスへ修正 -->
<string>/Users/hidenari/llama.cpp/build/bin/llama-server</string>
<string>-m</string>
<string>/Users/hidenari/models/Qwen3.5-9B-Q8_0.gguf</string>
<string>-c</string>
<string>65536</string>
<!-- 2. 最新版の引数名 (--n-gpu-layers) へ修正 -->
<string>--n-gpu-layers</string>
<string>99</string>
<string>--port</string>
<string>8080</string>
<!-- 3. 引数が必要になった --flash-attn の形式を修正 -->
<string>--flash-attn</string>
<string>on</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>WorkingDirectory</key>
<string>/Users/hidenari/models</string>
<key>StandardOutPath</key>
<string>/tmp/qwen35.log</string>
<key>StandardErrorPath</key>
<string>/tmp/qwen35_error.log</string>
</dict>
</plist>
2. M4 Max（Local）：9Bを瞬時に立ち上げる
次に、手元のM4 Maxで、最新の Qwen3.5-9B を起動する。 /Users/hidenari/models/ に移動し
あえての wget で落とした GGUF を叩く。
------Bash-----cd /Users/hidenari/models/ && ./llama-server \
-m Qwen3.5-9B-Q8_0.gguf \
-c 65536 \
--ngl 99 \
--port 8081 \
--flash-attn
エンジニアを30年以上やってきた。 フリーランスとして、今も現場でキーボードを叩き続けているのは、何よりも「達成感」を味わいたいからだ。
今回、手元に届いた M4 Max (Mac Studio) をメイン機に据えるにあたり、これまで現役だった M1 Max を「引退」させるのではなく、「自分専用のローカルLLM推論サーバー」として再定義することにした。
GPTに頼り切るのではなく、完全にクローズドな環境で、インフラ構成（Terraform）を自律的に爆速で組み上げる。そんな「理想のエンジニアリング環境」を構築した記録だ。
新旧のMac Studioが重なる姿は、エンジニアとしてのキャリアの積み重ねのようにも見える。 M1 Maxを llama.cpp サーバーとして稼働させ、M4 Max上の Continue（VS Code拡張）からSSH経由で命令を飛ばす。
この構成の肝は、電源アダプターすら不要なM4 Maxのパワーと、まだまだ現役でAIを回せるM1 Maxのメモリ帯域の共演にある。
AI（Qwen）に指示を出す中で、一つ気づいたことがある。 AIは「シニアエンジニア」という役割を与えると、教科書通りの「綺麗なモジュール分割」をしようとして自滅するのだ。
サブディレクトリを掘り、変数を渡し、複雑な構造を作ろうとして、結果的にLLMのコンテキストを使い果たしてエラーを吐く。 「しんどそうだな、お前」 画面の中のAIに、思わずそう声をかけそうになった。
そこで私は、19項目の「行動規範（Rules）」を再定義した。
モジュール分割の禁止: すべてをルート直下のファイル名（vpc.tf, ec2.tf等）で分ける「フラット構成」にする。
一気通貫の実行: フォルダ作成から validate まで、承認を待たずに一気に完遂させる。
日本語の徹底: 思考のノイズを減らすため、 Reasoning も含めてすべて日本語で行う。
ブログに技術的な裏付けを持たせるために、具体的な「足場」の部分を書き加えました。M1 Maxをサーバーにする際の実践的なノウハウとして、エンジニア読者が最も喜ぶセクションになります。
今回、Terraform構築の相棒に選んだのは Qwen2.5-Coder-32B だ。 これまで数多くのモデルを試してきたが、コーディングにおける「正確性」と、HCL（HashiCorp Configuration Language）の構造を理解する「論理力」において、現時点でのローカルモデルとしては群を抜いている。
M1 Maxの広帯域なユニファイドメモリ（64GB搭載機であればなおさら）なら、このクラスのモデルも驚くほど軽快に、かつ深いコンテキストを持って動かすことができる。
この Qwen を裏側で支えているのが llama.cpp だ。 ただ動かすだけではなく、M1 Max の GPU 性能を引き出し、かつ VS Code（Continue）からの要求に耐えうる「サーバー」として、私は以下のパラメータで叩いている。
./llama-server \
-m models/qwen2.5-coder-32b-instruct-q4_k_m.gguf \
-c 32768 \
--ngl 99 \
--host 0.0.0.0 \
--port 8080
設定のポイント：
-c 32768: コンテキストサイズを 32k まで拡張。Terraform の複数ファイルを一気に読み込ませるには、デフォルトでは到底足りない。
--ngl 99: GPU（Metal）に全レイヤーをオフロード。M1 Max の GPU コアをフルに使い切るための「魔法の数字」だ。
--host 0.0.0.0: M4 Max からネットワーク越しに叩くため、バインド先を広げておく。
SSH で繋いだ M1 Max のターミナルでこのコマンドを叩き、サーバーが立ち上がるログが流れる。 その瞬間、昨日の主力機だった M1 Max は、現代最強の「コーディング専用ブレイン」に生まれ変わる。
AIによるコード生成が当たり前になった今、エンジニアが次に求めるのは「自分のコードベースをすべて把握した上での提案」です。VS Code拡張の Roo Code（旧Cline） は、プロジェクト全体をスキャンして記憶する「セマンティック検索（RAG）」機能を備えています。
今回は、プライバシーとパフォーマンスを両立させるため、M4 Max Mac Studioのパワーをフル活用し、「すべてをローカル完結させる」 環境構築の全記録をまとめました。
巷の解説記事はDockerを使うものが多いですが、今回はインフラエンジニアらしく、Macネイティブバイナリとlaunchdを駆使して「軽量・常駐・爆速」を目指します。
脳 (LLM): LM Studio (qwen2.5-coder:32b)
翻訳機 (Embedding): LM Studio (nomic-embed-text-v2-moe)
本棚 (Vector DB): Qdrant (Macバイナリ版)
常駐化: macOS launchd
構築を始める前に、一番ハマりやすいポイントを潰しておきます。VS Codeはシステムのプロキシ設定を拾ってしまい、127.0.0.1 への通信すら外へ投げようとすることがあります。
settings.json に以下を追記し、VS Codeを完全に再起動（Cmd+Q）しておきましょう。
"http.proxySupport": "off"
Roo Codeが「コードの記憶」を保存するには、ベクトルデータベースの Qdrant が必須です。Dockerを使わずに導入する手順は以下の通り。
# 作業ディレクトリの作成
mkdir ~/qdrant && cd ~/qdrant
# Apple Silicon(aarch64)用バイナリのダウンロード
curl -L https://github.com/qdrant/qdrant/releases/latest/download/qdrant-aarch64-apple-darwin.tar.gz -o qdrant.tar.gz
# 解凍と実行権限の付与
tar -xvf qdrant.tar.gz
chmod +x qdrant
毎回手動で起動するのはスマートではありません。Macの起動時にバックグラウンドで動き、プロセスが落ちても自動復旧するように設定します。
cat << EOF > ~/Library/LaunchAgents/io.qdrant.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>io.qdrant</string>
<key>ProgramArguments</key>
<array>
<string>/Users/$(whoami)/qdrant/qdrant</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>WorkingDirectory</key>
<string>/Users/$(whoami)/qdrant</string>
<key>StandardOutPath</key>
<string>/Users/$(whoami)/qdrant/qdrant.log</string>
<key>StandardErrorPath</key>
<string>/Users/$(whoami)/qdrant/qdrant-error.log</string>
</dict>
</plist>
EOF
# サービスの登録と開始
launchctl load ~/Library/LaunchAgents/io.qdrant.plist
ps aux | grep qdrant
lsof -i :6333 # 6333ポートがLISTENしていればOK
対話用のモデルだけでなく、Embedding用のモデルもロードしておきます。
Local Server 画面で Start Server を実行。
ポート番号（デフォルト 1234）を確認。
重要: 設定パネルの CORS (Cross-Origin Resource Sharing) を ON にします。これがOFFだとVS Codeからのアクセスが拒絶されます。
VS CodeのRoo Code設定画面（インデックス作成）で以下を入力します。
エンベッダープロバイダー: OpenAI互換
ベースURL: http://127.0.0.1:1234/v1 （末尾の /v1 を忘れずに）
モデル: text-embedding-nomic-embed-text-v2-moe
モデルディメンション: 768
Qdrant URL: http://127.0.0.1:6333
M4 Max Mac Studio（36GB RAM）環境において、この構成でのリソース消費は驚くほど低いです。
待機時CPU: ほぼ 0%。
メモリ: Qdrant単体では数百MB程度。
インデックス作成時: ログ（tail -f ~/qdrant/qdrant.log）が流れる瞬間だけCPUを使いますが、バックグラウンドでの作業を妨げることはありません。
1992年からUnixを触り、インフラを見続けてきた人間にとっても、手元のマシンでこれほど高度な検索・推論基盤が完結するのは感慨深いものがあります。
一度デーモン化してしまえば、あとはAIがあなたの過去のコード資産をすべて把握した状態で、最高の相棒として機能してくれます。Dockerを使わずに構築したいMacユーザーの方は、ぜひ試してみてください。
悩み: Obsidianのメモが増えるたびに、検索が重くなる。
課題: 毎回ディスクをなめる従来の検索（アホアホマン方式）の限界。
解決策: 「DBを入れずに、M4 Maxのメモリに全て載せればいいじゃない」という富豪的発想。
ハードウェア: Mac Studio (M4 Max / 36GB RAM) の圧倒的スペック紹介。
ソフトウェア: MCP (Model Context Protocol) サーバーを自作。
ロジック: 起動時に全メモを Map オブジェクトにロード。検索は String.includes() だけの爆速処理。
「10万件載っても大丈夫」の試算: 実際、テキスト10万件なら数百MBで収まるという「気づき」。
バックアップ機能: write_note 時の .bak 生成というプロの配慮。
キャッシュ同期: ファイルを書き換えた瞬間にメモリも更新するリアルタイム性。
AIとの親和性: ヒット箇所の「前後数十文字（Excerpt）」をAIに渡すことで、回答精度を高める工夫。
以下、サンプルコード
------
簡単な指示で、依頼するとコンテキストオーバーで記憶喪失になって コードの内容が一致しないことが起こるので、work.mdみたいな作業メモを取らせたるのがよい 途中から、別スレッドに再実施する場合でも、work.mdが引き継ぎとして 参照して実施してくれるのがポイント
