Ollama で Qwen3 を動かす初心者ガイド — 日本語最強ローカルLLMを自分のPCで使う方法

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 などのエージェントのバックエンドとして使うことも可能です。 ...

2026年3月4日 · 5 分

OpenHands 入門ガイド — 無料・オープンソースの AI コーディングエージェントを自分の PC で動かす

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)でも動作します。 ...

2026年3月4日 · 3 分

Skills の自動最適化 — TextGrad を応用して提案書生成スキルを「学習」させる実験と過学習の発見

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

2026年3月4日 · 3 分

Subagent と Agent Teams の違い — 「働くエージェント」と「議論するエージェント」を設計レイヤで理解する

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 のメンバーは完全に独立したセッションとして動作し、互いに直接メッセージを送受信できます。リードを介さずに横の連携が可能です。 ...

2026年3月4日 · 3 分

ハーネスエンジニアリング実践知 — 「AIを使う人」と「AIを設計する人」の決定的な差

ハーネスエンジニアリング実践知 — 「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 ヶ月間の実験です。 ...

2026年3月4日 · 4 分

ローカル LLM を社内業務に特化させる 4 段階カスタマイズ — Qwen3 を「より賢く」する仕組み

ローカル 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 で十分な精度が得られます。 ...

2026年3月4日 · 15 分

.envの代わりにaws-vaultで安全に環境変数を与える — Claude Code時代のAWS認証情報管理

.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 アクセス時の追加のパスワードプロンプトが少なくなります。 ...

2026年3月3日 · 6 分

.envの代わりにlkrでLLM APIキーを安全に管理する — セットアップからClaude Code連携まで

.env の代わりに lkr で LLM API キーを安全に管理する — セットアップから Claude Code 連携まで AI エージェントがローカルファイルを読み書きする時代、.env に平文で置いた API キーが LLM のコンテキストに載るリスクが現実のものになっています。前回の記事ではこの問題の全体像を、aws-vault の記事では AWS 認証情報の保護を解説しました。 本記事では、LLM Key Ring(lkr)を使って LLM API キーを安全に管理する具体的な手順を解説します。aws-vault が AWS 認証情報に特化しているのに対し、lkr は OpenAI・Anthropic・Google など LLM API キーの管理に特化したツールです。 lkr が解決する問題 .env に LLM API キーを置くリスク 多くの開発者は .env ファイルに API キーを平文で保存しています。 1 2 3 # .env(平文で保存されている) OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxx ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx このファイルには4つの攻撃ベクトルがあります。 攻撃ベクトル 説明 Git への混入 .gitignore に頼るヒューマンエラー。うっかりコミットは後を絶たない シェル履歴への漏洩 export OPENAI_API_KEY=sk-... が ~/.bash_history に残る プロセス情報への露出 ps コマンドで環境変数が見える AI エージェントによる抽出 Claude Code がファイルを読み取り、LLM の API リクエストに含まれる 4番目が AI 時代に特有の脅威です。Claude Code は.env ファイルを自動的に読み込むことが確認されており、API キーが意図せず Anthropic のサーバーに送信されるリスクがあります。 ...

2026年3月3日 · 8 分

「上位 1% の Claude Skills 構築方法」を技術的に読み解く --- スキルの構造・設計パターン・組織展開

「上位 1% の Claude Skills 構築方法」を技術的に読み解く — スキルの構造・設計パターン・組織展開 @sales_muscle 氏が X で投稿した、Claude Skills の構築ガイドが反響を呼んでいます。 上位1%のClaude Skills構築方法 投稿では、AI 活用の基準が「プロンプトのうまさ」から「AI にスキル(専門能力)を組み込み、組織の資産にできるか」へ移行したと主張しています。本記事では、この投稿の内容を Claude Code の公式ドキュメントと照らし合わせ、スキルの技術的な構造と実践的な設計パターンを掘り下げます。 Claude Skills とは何か プロンプトからスキルへの進化 投稿の核心は「指示(プロンプト)からスキルへ」という転換です。これは技術的に正確な指摘です。 従来の AI 活用: ユーザー → プロンプトを毎回書く → AI が回答 問題: 知識がチャットセッションに閉じる、再現性がない スキルベースの AI 活用: ユーザー → /skill-name で呼び出す → AI がスキルの手順に従って実行 利点: 再現性あり、共有可能、自動呼び出し対応 Claude Code 公式ドキュメントによると、スキルは「SKILL.md ファイルに指示を書き、Claude のツールキットに追加する」仕組みです。Claude は関連するタスクで自動的にスキルを読み込むか、/skill-name で直接呼び出せます。 スキルの技術的な定義 スキルは単なるプロンプトテンプレートではなく、以下の要素を持つ構造化されたモジュールです。 要素 役割 YAML フロントマター 名前、説明、呼び出し制御、許可ツールなどのメタデータ Markdown 本文 Claude が従う具体的な手順・ルール サポートファイル テンプレート、例、スクリプトなどの補助リソース 文字列置換 $ARGUMENTS、$0、${CLAUDE_SESSION_ID} などの動的値 スキルは Agent Skills オープン標準に準拠しており、Claude Code 固有の機能ではなく、複数の AI ツールで動作する標準仕様です。 ...

2026年3月3日 · 3 分

AI が書いたコードに「なぜそうなったか」の記録はあるか --- git-memento と AI コード追跡の新標準

AI が書いたコードに「なぜそうなったか」の記録はあるか — git-memento と AI コード追跡の新標準 @SatoshiSsSs 氏が X で投稿した、git-memento に関する解説が注目を集めています。 AIが書いたコードに「なぜそうなったか」の記録はあるか? Hacker News(HN)で議論になっている git-memento を読み解く Hacker News での議論では、AI が生成したコードのセッション履歴をコミットに紐づけるべきか否かが活発に議論されています。AI コーディングの普及とともに、「コードは動くが、なぜその実装になったのか誰も分からない」という問題が深刻化しています。本記事では、この問題の構造と、git-memento をはじめとする解決策の技術的な仕組みを掘り下げます。 問題 — AI が書いたコードの「なぜ」が消えている Vibe Coding 時代の追跡可能性の危機 2026 年、AI コーディングツール(Claude Code、Cursor、GitHub Copilot など)でコードを書くことが日常になりました。しかし、AI が生成したコードには構造的な問題があります。 従来の開発: 開発者が考える → コードを書く → コミットメッセージに意図を記録 → 「なぜそうしたか」は開発者の頭の中 + コミット履歴にある AI 駆動開発: 開発者が指示する → AI が考える → AI がコードを書く → コミット → 「なぜそうなったか」は AI セッションの中に閉じている → セッションが終わると消える CodeRabbit の分析(2025 年 12 月)によると、AI と共著されたコードは人間が書いたコードと比較して、ロジックエラーが 75% 多く、セキュリティ脆弱性が 2.74 倍多いとされています。問題が発見されたとき、「なぜこの実装になったのか」を遡れなければ、修正の方針すら立てられません。 ...

2026年3月3日 · 4 分