Claude-Code

Claude Code 起動画面のオレンジの生き物「Clawd」の正体 — カニ？タコ？誰も知らない公式マスコットの謎 @koder_dev 氏のポストが、多くの Claude Code ユーザーが抱えていた疑問を代弁しています（いいね 301、RT 78）。 Claude Code起動するたび出てくるオレンジの生き物、お前誰だよってずっと思ってたけどZennで正体暴いてる記事あって面白かった 良かった、気になってるの自分だけかと思った笑 引用元は tutupizizizi 氏による Zenn 記事「Claude Codeを起動するたび出てくるオレンジの生き物、お前は一体何なんだ」。Claude Code を起動するたびにターミナルに現れるオレンジ色の8ビットピクセルアートの正体を、ソースコードまで追って調査した記事です。 本記事では、この謎のマスコット「Clawd」について、公式情報・コミュニティの議論・ソースコードの調査結果をまとめます。 Clawd とは何か 基本情報 Claude Code を起動すると、ターミナルの上部に ASCII アートで描かれたオレンジ色の生き物が表示されます。これが Clawd（クロード）です。 ████████████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██████████ ██ ██ ██ ██ ██ ██ ██ ██ ██ （実際の表示はターミナルの Unicode ブロック文字で描画されます） 項目 内容 名前 Clawd 読み方 クロード（Claude と同じ発音） 名前の由来 「Claude」+「Claw（爪）」のダジャレ 公式絵文字 🦀 初登場 Claude Code の初期バージョンから デザイン 8ビットピクセルアート風 通常の色 オレンジ 種族は公式に未定義 Clawd の最大の謎は、Anthropic が公式に「何の生き物か」を明言していないことです。このため、コミュニティは3つの派閥に分裂しています。 ...

Claude Cowork を最強にする 17 の方法 — プロンプトではなく「設計」で差がつくシステム工学 @masahirochaen 氏が X で投稿した、Claude Cowork のベストプラクティス解説が反響を呼んでいます。 海外でバズった「Claude Cowork を最強にする 17 の方法」の学びが深い。プロンプト力ではなく「仕組み」で差がつく 元になっているのは @heynavtoor（Nav Toor）氏の X Article「17 Best Practices That Make Claude Cowork 100x More Powerful」です。Nav Toor 氏は 2026 年 1 月 12 日から Cowork を使い始め、7 週間で 400 セッション以上を重ねた経験をもとに、Anthropic が公式ドキュメントに書いていない 17 の実践法をまとめています。いいね 3,194、ブックマーク 13,149、閲覧 188 万超と大きな反響を得ました。本記事では、この 17 の方法を技術的に掘り下げて解説します。 Claude Cowork とは Claude Code との違い Claude Cowork は、Anthropic が提供する非エンジニア向けの AI エージェント環境です。Claude Code がターミナルベースの開発者向けツールであるのに対し、Cowork は Claude デスクトップアプリ内で動作する GUI ベースの作業環境です。 ...

GitHub Copilot CLI の /research コマンド — コミットログも Actions 履歴も全部調べてくれるディープリサーチ @07JP27 氏が X で連続投稿し、GitHub Copilot CLI の /research コマンドの威力を紹介しています。 /research コマンドすげえ。Web を Deep Research してくれるのはもちろん、紐づくリポジトリのコミットログとか GitHub Actions の実行履歴まで全部見てくれて「お前のこのときのコミットのここが原因だぞ。Actions のログにもこう出てるだろ」みたいなことを言ってくる。 元の投稿では Qiita 記事（@shyamagu 氏の解説）も参照されており、MCP ツール連携や WorkIQ との統合例が紹介されています。本記事では、/research コマンドの技術的な仕組みと、Claude Code との比較を交えて解説します。 /research コマンドとは 概要 2026 年 2 月 25 日、GitHub Copilot CLI が全有料プラン向けに一般提供（GA）を開始しました。同日リリースの v0.0.417 で追加された /research コマンドは、ディープリサーチ専用のスラッシュコマンドです。 通常のチャットが速度重視なのに対し、/research は徹底性（thoroughness）を重視します。複数のツールを呼び出しながら情報を収集し、数百行に及ぶ Markdown レポートを生成します。 1 2 3 4 5 # 基本的な使い方 /research Azure App Service の 2026 年の新機能 # MCP ツールを明示的に指定 /research microsoft-docs ツールを使って Azure App Service の新機能を調査してください 3 つのクエリ分類 /research はクエリを自動分類し、回答形式を最適化します。 ...

Ollama で Qwen3 を動かす初心者ガイド — 日本語最強ローカル LLM を自分の PC で使う方法 「ChatGPT みたいな AI を、自分の PC だけで動かせたら」と思ったことはありませんか。Ollama と Qwen3 を使えば、それが実現できます。この記事では、Saiteki AI の解説記事をベースに、初心者でもわかるように Ollama と Qwen3 の導入手順をまとめました。 まず知っておきたい：LLM・ランタイム・エージェントの 3 層構造 AI の世界には、混同しやすい 3 つの概念があります。この記事で扱う Ollama と Qwen がどこに位置するかを最初に整理しましょう。 レストランに例えると お客さん（あなた） ↓ 「パスタを作って」 ウェイター（AI エージェント） ← 注文を聞き、判断し、段取りを組む ↓ 「この食材でこう調理して」 キッチン設備（ランタイム） ← オーブンや鍋。料理を物理的に実行する環境 ↓ シェフの腕＝レシピの知識（LLM） ← 実際に「どう調理するか」を知っている頭脳 層 役割 具体例 自分で判断するか LLM（AI モデル） 言葉を理解し、回答を生成する「頭脳」 Qwen3, Llama3, Gemma2 しない（聞かれたことに答えるだけ） ランタイム LLM をメモリに読み込み、動かす「実行環境」 Ollama, vLLM, llama.cpp しない（言われた通り動かすだけ） AI エージェント LLM を使って自律的に「仕事」をこなすプログラム Claude Code, Devin, Dify する（目標に向かって複数ステップを自分で組み立てる） 3 つの関係 AI エージェント（Claude Code など） ↓ 「この質問を LLM に投げて」 ランタイム（Ollama など） ↓ モデルをメモリに読み込んで推論実行 LLM（Qwen3 など） ↓ 回答を生成 ランタイム → エージェントに結果を返す LLM は「頭脳」。質問されたら答えを返すが、自分からは何もしない ランタイム は「エンジン」。LLM を動かすが、何を質問するかは決めない エージェント は「ドライバー」。ランタイム経由で LLM を呼び出し、結果を見て次の行動を自分で決める この記事で扱うのは、LLM（Qwen3）とランタイム（Ollama）の 2 つです。 エージェントは含みませんが、Ollama で動かした Qwen3 を Claude Code や Dify などのエージェントのバックエンドとして使うことも可能です。 ...

OpenHands 入門ガイド — 無料・オープンソースの AI コーディングエージェントを自分の PC で動かす OpenHands とは OpenHands（旧 OpenDevin）は、AI が自律的にコードを書き、デバッグし、テストを実行するオープンソースのコーディングエージェントです。MIT ライセンスで完全無料、GitHub で 68,000 スター以上を獲得し、479 名以上のコントリビューターが参加しています。 簡単に言えば、「Claude Code や Devin のオープンソース版」です。自然言語で「この関数のテストを書いて」「このバグを直して」と指示するだけで、AI がファイルを読み、コードを編集し、ターミナルでコマンドを実行して、タスクを完了させます。 LLM・ランタイム・エージェントの 3 層構造における位置づけ AI ツールを理解する上で、3 つの層を区別することが重要です。 あなた ↓ 「このバグを直して」 エージェント（OpenHands） ← コードを読み、修正し、テストを実行する「ドライバー」 ↓ 「この質問を LLM に投げて」 ランタイム（Ollama 等） ← LLM を動かす「エンジン」 ↓ LLM（Qwen3, Claude 等） ← 回答を生成する「頭脳」 層 役割 OpenHands の場合 LLM 言語理解・コード生成 Claude, GPT, Qwen3 など（選択可能） ランタイム LLM の実行環境 Anthropic API / OpenAI API / Ollama エージェント 自律的にタスクを遂行 OpenHands がここ OpenHands の最大の特徴はモデル非依存であることです。クラウド API（Claude, GPT）でも、ローカル LLM（Ollama + Qwen3）でも動作します。 ...

Skills の自動最適化 — TextGrad を応用して提案書生成スキルを「学習」させる実験と過学習の発見 @yusuke_post 氏が、Claude Code の Skills を深層学習の手法で自動最適化する実験を公開し、大きな反響を呼んでいます。 最初のポスト（いいね 1,226、ブックマーク 2,265）では TextGrad を応用した Skills 最適化の概念を紹介し、続報のポスト（いいね 126、ブックマーク 132）では追加実験の結果として以下の知見を報告しています。 わかったのは、 ・３イテレーションくらいで過学習する。 ・１回だけでなく、3回くらいイテレーションを回すことで徐々にスコアが改善する。 ・学習を始めて最初の方は、「提案書に何を書くか」を学び出して、最後の方では「提案書のそれぞれの項目をどう書くか」を自動で学習する。 特に「全体最適→局所最適の順番で AI が自動で学んだ」という発見は、深層学習の訓練過程と同様の振る舞いが Markdown のプロンプトでも起きることを示唆しています。本記事では、この実験の背景・手法・発見を解説します。 TextGrad とは何か 「テキスト版の誤差逆伝播」 TextGrad（論文: arXiv 2406.07496）は、Stanford 大学の Zou グループが開発し、Nature に掲載されたフレームワークです。深層学習における誤差逆伝播（backpropagation）の概念を、テキストに適用します。 [深層学習の最適化] 入力 → ニューラルネット → 出力 → 損失関数 → 勾配計算 → パラメータ更新 ↑ 数値の勾配 [TextGrad の最適化] 入力 → LLM → 出力 → 評価（LLM） → テキスト勾配 → プロンプト更新 ↑ 自然言語のフィードバック 従来の深層学習では数値的な勾配を計算してパラメータを更新しますが、TextGrad では LLM が自然言語で「どう改善すべきか」をフィードバックし、それを「テキスト勾配」としてプロンプトを更新します。 ...

Subagent と Agent Teams の違い — 「働くエージェント」と「議論するエージェント」を設計レイヤで理解する @dify_base 氏のポストが、Claude Code の Subagent と Agent Teams の違いを図解で整理しています。 Claude Code の「Subagent」と「Agent Teams」の違い、意外と知らない人が多いので、図解で整理しました👇 ✅Subagent → 調査して結果を返すだけの部下 ✅Agent Teams → 複数AIが議論・協力する自律チーム この2つの機能は名前が似ていて混同しやすいですが、設計思想が根本的に異なります。本記事では、公式ドキュメントと Qiita の設計レイヤ分析記事を基に、両者の違いを構造的に解説します。 一言で言う違い Qiita の記事が最も端的に表現しています。 Subagent は「働くエージェント」、Agent Teams は「議論するエージェント」 Subagent Agent Teams 一言で 調査して結果を返す部下 議論・協力する自律チーム 比喩 上司に報告するだけの社員 横で相談し合うプロジェクトチーム 構造的な違い — 通信モデルが本質 Subagent: スター型（親子通信のみ） メインエージェント ／ ｜ ＼ Subagent Subagent Subagent (Explore) (Plan) (general) Subagent はメインエージェントの単一セッション内で動作します。結果をメインエージェントに返すことしかできず、Subagent 同士は直接通信できません。 Agent Teams: メッシュ型（全方向通信） リード（チームリーダー） ／ ｜ ＼ Teammate Teammate Teammate (API) (UI) (Test) ＼ ｜ ／ 共有タスクリスト Agent Teams のメンバーは完全に独立したセッションとして動作し、互いに直接メッセージを送受信できます。リードを介さずに横の連携が可能です。 ...

ハーネスエンジニアリング実践知 — 「AIを使う人」と「AIを設計する人」の決定的な差 まさお(@AI_masaou) 氏が、Claude Code のハーネス（開発基盤）をテーマにした約 80 分の対談形式勉強会のまとめ記事を公開しました。 新しい note を公開しました！ハーネスエンジニアリングに向き合う上で、実践的にはどうしているのか？の勉強会を行いましたのでそのまとめを記事にしました — @AI_masaou 元記事（ハーネスエンジニアリングの実践知を共有！【質問/勉強会のまとめ】）は有料コンテンツのため、本記事ではテーマであるハーネスエンジニアリングの実践知について、公開情報をもとに技術的な背景と具体的な手法を解説します。 ハーネスエンジニアリングとは 「ハーネス」とは馬具のことです。馬の力をそのまま放置すれば暴走しますが、ハーネスで制御すれば有用な仕事に変わります。AI エージェントも同じです。LLM の推論能力をそのまま使うのではなく、適切な制御基盤（ハーネス）で囲むことで信頼性の高い成果に変換するのがハーネスエンジニアリングです。 コンピュータの構成に対応させると、位置づけがわかりやすくなります。 コンピュータ AI エージェント CPU LLM（推論エンジン） OS エージェントハーネス（制御・管理基盤） アプリケーション AI エージェント（実行層） CPU がどれだけ高速でも、OS が適切に管理しなければアプリケーションは動きません。同様に、LLM がどれだけ賢くても、ハーネスの設計が悪ければエージェントの出力品質は上がりません。 コンテキストエンジニアリングとの関係 Andrej Karpathy が X で提唱した「コンテキストエンジニアリング」 は、ハーネスエンジニアリングの中核概念です。 Context engineering is the delicate art and science of filling the context window with just the right information for the next step. — Andrej Karpathy LLM のコンテキストウィンドウを「RAM」と捉え、次のステップに必要な最適な情報だけを入れる技術です。ハーネスエンジニアリングはこのコンテキスト管理の仕組み全体を包む上位概念にあたります。 ハーネスエンジニアリング（全体設計） ├── コンテキストエンジニアリング（何を LLM に渡すか） ├── 権限制御（何を許可・禁止するか） ├── ライフサイクル自動化（いつ何を実行するか） └── 並列実行・隔離（どう安全に並列化するか） 「環境設計 > モデル能力」— OpenAI Codex チームの実証 ハーネスエンジニアリングの重要性を最も説得力をもって示したのが、OpenAI のエンジニアリングチームによる 5 ヶ月間の実験です。 ...

ローカル LLM を社内業務に特化させる 4 段階カスタマイズ — Qwen3 を「より賢く」する仕組み Claude Code で生成したコードをローカル LLM（Ollama + Qwen3）でレビューする構成を前回の記事で紹介しました。しかし、汎用モデルのままでは「受注ステータスの遷移ルール」や「金額計算に float を使ってはならない」といった社内固有のルールを知りません。 この記事では、Qwen3 を社内業務に特化させ、特定のコーディング規約・業務ルール・過去の障害パターンを踏まえたレビューができるようにする 4 段階のカスタマイズ手法を紹介します。 全体像：4 段階のカスタマイズ レベル 手法 導入期間 効果 専門知識 1 Modelfile（システムプロンプト） 即日 ルールベースの指摘 不要 2 RAG（社内ドキュメント検索） 1〜2 日 文脈を踏まえた指摘 Docker の基本 3 Few-shot（レビュー事例の学習） 数日 パターン認識の向上 不要 4 LoRA ファインチューニング 1〜2 週間 モデル自体の精度向上 Python・ML の基本 レベル 1：ルールを「教える」 ← すぐできる レベル 2：資料を「渡す」 ← 1〜2日 レベル 3：お手本を「見せる」 ← 数日 レベル 4：頭脳を「鍛える」 ← 1〜2週間 推奨: レベル 1 から順に導入し、効果を確認しながらステップアップしてください。多くの場合、レベル 1 + 2 で十分な精度が得られます。 ...

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理 AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。 本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。 aws-vault が解決する問題 ~/.aws/credentials の平文問題 AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。 1 2 3 4 # ~/.aws/credentials（平文で保存されている） [default] aws_access_key_id = AKIAIOSFODNN7EXAMPLE aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY このファイルには2つのリスクがあります。 Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある 長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける aws-vault のアプローチ aws-vault は以下の2段階で問題を解決します。 暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する 一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する [従来] ~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り → 長期キーがメモリに残る [aws-vault] macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成 → 子プロセスに環境変数として注入 → 1時間で失効 セットアップ インストール 1 2 3 4 5 6 7 8 9 10 11 12 13 # macOS（推奨） brew install --cask aws-vault # macOS（Homebrew formula 版） brew install aws-vault # Linux brew install aws-vault # Windows choco install aws-vault # または scoop install aws-vault macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。 ...