AI/LLM

r.kagaya 氏（@ry0_kaga、AstarMinds CTO）が Zenn に公開した記事がある。「ハーネスエンジニアリングとは何で、何ではないのか 〜作る側のハーネス、使う側のハーネス〜」という記事だ。ハーネスエンジニアリングをめぐる言葉の混乱を整理し、エージェントハーネスとユーザーハーネスという2層の区分を提示している。 CLAUDE.md や Skills を書けば「ハーネスエンジニアリングをやっている」と言える。でも、それはハーネスエンジニアリングの全体ではない。この記事ではその全体像を整理する。 そもそも「ハーネス」の定義が割れている 前提として、ハーネスエンジニアリングという言葉には統一された定義がない。同じ言葉を使いながら、各社・各人が指しているものが違う。 用語の来歴 「ハーネス」の原義は馬具だ。馬を馬車に繋ぎ、方向を制御し、力を伝達する装備。ソフトウェア文脈では 2020 年の lm-eval-harness（言語モデル評価ハーネス）が初出とされる（r.kagaya 氏による整理）。2024 年に All Hands AI / OpenHands が「エージェントハーネス」に拡張。2026 年に Mitchell Hashimoto（Terraform 創業者）が「Engineer the Harness」と命名し、OpenAI の記事で広まった。 各社の定義 誰が 何と言っているか LangChain (Vivek Trivedy) 「Agent = Model + Harness。モデルでなければハーネス」 Anthropic 「LLM を呼び出し、ツールコールをルーティングする制御ループ」 OpenAI 宣言的制約 + サンドボックス + スケーリング Böckeler / Martin Fowler サイバネティクス的制御。フィードフォワード × フィードバック Phil Schmid (Hugging Face) Model = CPU, Harness = OS Bedi (Composio CEO) 「システムエンジニアリングのサブセットに新しい名前をつけているだけ」 LangChain の「モデルでなければハーネス」は極めて広い。Anthropic の「制御ループ」はエージェント実装寄り。「そもそも新しい概念ですらない」と言う人もいる。さらにベンダー（作り手）と利用者（使い手）で意味が違うという構造的な問題もある。 ...

AWS が公開した「AI 駆動の業務変革手法 AI BPR」の記事が話題になっている。単なる成功事例ではなく、「正しいアプローチが全く機能しない」という壁に正直にぶつかった失敗報告から始まる点が異色で、AI 導入に苦戦する多くの組織にとって示唆に富む内容だ。 AWS が3ヶ月間で発見した「正しいアプローチが機能しない」現実 AWS は自社で3ヶ月間、お客様に AI エージェント導入プログラムを提供してみた。最初に試みたのは、いわゆる BPR の教科書通りのアプローチだ。 ゴール設定 業務フロー分析 ボトルネック特定 AI エージェントで解決 計測 整然としたフローに見えるが、現場から返ってきた反応は想定外だった。 「AI エージェントに任せるのは BCP 上危険」 「提案の枠が狭くて大きな進歩を感じない」 一見もっともらしい抵抗なのだが、よく分解すると全然別の構造が見えてくる。 抵抗の本質：2つの根本的障壁 1. アイデンティティへの脅威 長年積み上げてきた専門性が AI に代替されることへの「存在意義の危機」だ。Stanford の研究でも、45% が AI の精度を懸念し、23% が職の代替を恐れているという。これは能力の問題ではなく存在意義の問題であり、ツール改善では解決できない。 2. 責任の所在を人間に残したい組織心理 「この業務は◯◯さんが詳しい」という言葉の裏を返せば、責任分担の合意だ。AI に委譲するということは、業務停止時の責任も IT 部門に一気に流れ込むということ。それは組織として受け入れがたい。 この2つが合わさると、「やっぱり人間でないと難しい」という一見合理的な「落としどころ」に着地してしまう。AWS はこれを Argyris の言う防衛的ルーティン（defensive routines）・熟達した無能力（skilled incompetence）と結びつけて説明しており、ここが本当に鋭い。 アプローチの転換：「課題は何ですか？」を捨てる AWS が下した判断は、AI BPR を一旦抜本的に見直してゼロから組み直すことだった。 従来の「課題は何ですか？」という問いかけをやめ、「強みは何ですか？」から入る設計に変えた。 「課題は何ですか？」という問い自体が、実は防衛反応を誘発する最悪のフレームだったという発見も重要だ。問題を分析して修正するアプローチは、当事者を「自分たちは問題を抱えた存在」として位置づけてしまう。 Appreciative Inquiry の採用 具体的に採用したのが、Cooperrider & Srivastva が提唱した Appreciative Inquiry（アプリシエイティブ・インクワイアリー、以下 AI）という手法だ。 問題を分析して修正するのではなく、組織の既存の強みと成功体験を発見して増幅することで変革を起こす。 Appreciative Inquiry とは何か AI は 1987 年に Case Western Reserve University の David Cooperrider と Suresh Srivastva が発表した組織開発手法だ。Cooperrider の博士論文（1986 年）が出発点で、以後 40 年近く理論的な拡張と実践が積み重ねられてきた。日本でも 2005 年以降、ヒューマンバリュー社が Diana Whitney を招聘して『ポジティブ・チェンジ』として翻訳・紹介したことで広まっている。 ...

「自分のPCでローカルAIを動かしたい、でもどのモデルが動くか分からない」。そんな悩みを一発で解決してくれる Web サービスが CanIRun.ai だ。インストール不要、登録不要で、サイトにアクセスするだけでハードウェアを自動検出し、数百のモデルに対して動作可否を判定してくれる。 何ができるのか CanIRun.ai は、ブラウザの WebGPU API を使って以下のハードウェア情報を自動取得する。 GPU の種類と VRAM 容量（GPU 名を WebGPU/WebGL で取得し、内部 DB から VRAM を割り出す） GPU メモリ帯域幅（内部スペックシート DB から参照） システム RAM CPU コア数 取得した情報をもとに、カタログに登録された全モデルとの適合性を即座に算出する。 6 段階の互換性評価 各モデルに対して、S〜F の 6 段階グレード が色分けで表示される。 グレード ラベル 意味 S Runs great 余裕で動作 A Runs well 快適に動作 B Decent まずまず動作 C Tight fit ギリギリ動作 D Barely runs かろうじて動作 F Too heavy 動作不可 グレードに加え、アーキテクチャの種類・コンテキストウィンドウサイズ・量子化レベル（Q2_K〜F16 といった精度とサイズのトレードオフを示すレベル）ごとのメモリ要件など、詳細な技術情報も確認できる。 対応モデルの幅広さ カタログは 1GB 未満の軽量モデルから数百 GB の巨大モデルまで 網羅している。 ...

スタートアップコミュニティで知名度の高い Greg Isenberg が、Obsidian と Claude Code を組み合わせて「24時間365日稼働するパーソナル AI オペレーティングシステム」を構築する方法を公開した。閲覧数 110 万超、ブックマーク 17,000 超と大きな反響を呼んでいる。 なぜ Obsidian × Claude Code なのか 多くの人は AI を「汎用チャットボット」として使っている。セッションを開くたびに自己紹介し、プロジェクトの背景を説明し直す——この繰り返しが生産性のボトルネックになっている。 Greg が提案するアプローチは、自分の思考・知識・文脈をすべて Obsidian ボルト（ノート群）に蓄積し、Claude Code がそれを読み込んで行動するというものだ。人間が書き、AI が読んで実行する、という明確な役割分担がポイントになる。 10 ステップで始めるパーソナル OS ステップ 1: 全てを Markdown で書く 日報・プロジェクト概要・自分の信念・人脈・議事録——あらゆる情報を Markdown ファイルとして Obsidian ボルトに記録する。フォーマットを統一することで、Claude Code が構造的に読み取れるようになる。 1 2 3 4 5 6 7 8 9 10 11 vault/ ├── daily/ │ └── 2026-04-22.md # 日報 ├── projects/ │ └── my-startup.md # プロジェクト概要 ├── people/ │ └── john-doe.md # 人脈メモ ├── beliefs/ │ └── product-philosophy.md # 信念・哲学 └── meetings/ └── 2026-04-22-kickoff.md # 議事録 ステップ 2: ノート同士を自分の思考回路のようにリンクする [[プロジェクト名]] 形式のウィキリンクでノートを繋ぎ、自分の思考の連鎖を反映させる。単なるメモの集合ではなく、考え方のグラフを構築することが目的だ。 ...

Google の NotebookLM に触発されたオープンソース実装 open-notebook が海外のテック界隈で注目を集めている。データを一切外部に送信しない完全ローカル動作を売りに、Docker で約2分で立ち上げられる手軽さも人気の理由だ。 open-notebook とは open-notebook は、NotebookLM の主要機能をすべて再実装した OSS プロジェクト。2024年10月に公開され、2026年4月時点で 22,000 スター超 を獲得している。 公式サイト: open-notebook.ai 主な機能 マルチソースの知識統合 PDF・動画・音声・ウェブページを横断で読み込ませ、AI とのチャット形式で対話できる。NotebookLM と同様の使い勝手を、完全ローカル環境で実現する。 多数の AI バックエンドに対応 OpenAI・Anthropic（Claude）・Google Gemini・Ollama・Mistral・Groq・xAI・Deepseek など主要なプロバイダーを幅広くサポートしている。 バックエンド 備考 Anthropic (Claude) クラウド OpenAI (GPT) クラウド Google Gemini クラウド Ollama ローカル・完全無料 Mistral / Groq / xAI / Deepseek など クラウド Ollama を選択すれば、外部サービスへの通信がゼロのオフライン環境でも完全無料で運用できる。 ポッドキャスト風音声の生成 複数の話者でポッドキャスト形式の音声を自動生成できる。NotebookLM が2人固定なのに対し、open-notebook は話者数をカスタマイズ可能な点が差別化ポイント。 REST API 完備 REST API が標準搭載されているため、企業内アプリへの組み込みや外部サービスとの連携が容易。n8n や LangChain などのワークフローツールからも呼び出せる。 日本語 UI 対応 インターフェースが日本語に対応しており、日本のユーザーでもすぐに使い始められる。 ...

2026 年 3 月末、Alibaba は alibaba/anolisa を公開しました。これは同社が保守するサーバー向け Linux ディストリビューション Anolis OS を AI Agent 実行基盤として再構築した「Agentic OS」プロジェクトで、正式名称は ANOLISA（Agentic Nexus Operating Layer & Interface System Architecture）です。 本記事では、ANOLISA が解こうとしている問題と、公開されている 4 つのコアコンポーネント（Copilot Shell / Agent Sec Core / AgentSight / OS Skills）の役割、そして開発者が今すぐ触れられる導入手順を整理します。 ANOLISA が目指すもの ANOLISA は Anolis OS の「Agentic 進化版」と位置づけられており、AI Agent ワークロードをサーバー側で安全かつ観測可能な形で動かすためのベストプラクティス実装を狙っています。LLM / Agent がコード編集・シェル実行・ネットワークアクセス・プロセス管理といった OS レベルの操作を当たり前に行う時代において、「アプリケーション境界で守る」従来型セキュリティでは不十分になってきました。ANOLISA はその問題意識を背景に設計されています。 リポジトリ: alibaba/anolisa ホームページ: agentic-os.sh ライセンス: Apache License 2.0 主言語: TypeScript（Copilot Shell）/ Rust（AgentSight）/ C（eBPF プローブ） 公開: 2026 年 3 月 30 日（初版リポジトリ作成） 4 つのコンポーネント ANOLISA は単一のカーネルモジュールではなく、Agent 実行に必要な「シェル・セキュリティ・観測・スキル」を別々のプロダクトとして分離し、RPM で同居運用する構成を取っています。 ...

「もう 2 ヶ月以上、手でコードを書いていない」 Claude Code の生みの親であり、Anthropic でその開発を率いる Boris Cherny がそう語ったのは 2026 年 1 月のことだ。Andrej Karpathy の問いかけに応え、X への投稿でこう明かした。 “For me personally, it has been 100% for two+ months now, I don’t even make small edits by hand.” そして今、そのワークフローが広く注目を集めている。2 日間で 49 の Pull Request を出荷、コードは 100% AI 生成という実績が報告され、X では 30 分間のセッション動画が公開され 300 万回近く再生された。 Boris Cherny とは Boris Cherny は、Claude Code を 2024 年 9 月に社内の個人プロジェクトとして始めた人物だ。当初は自分のコーディングを助けるためのツールだったが、Anthropic 社内でその有効性が認められ、正式なプロダクトへと進化した。 彼は後にこう振り返っている。 “When I created Claude Code as a side project back in September 2024, I had no idea it would grow to what it is today.” ...

Claude Code の Skills を使い込むうちに「あれ、前と挙動が違う……」と感じたことはないだろうか。~/.claude/settings.json に 1 行追記するだけで解決できる。原因は auto-memory だ。 Claude Code の auto-memory が Skills の挙動を変える仕組み Claude Code は会話のたびに学習内容を Memory（~/.claude/projects/.../memory/MEMORY.md）へ自動で書き込む機能（auto-memory）を持っている。 問題はこの Memory の内容が次の会話でコンテキストウィンドウに自動挿入される点だ。これにより、Skills に記述した指示と競合し、設計どおりの挙動から少しずつずれていく。 会話を重ねるほど症状が顕著になるため、原因の特定に時間がかかりやすい。 解決策：autoMemoryEnabled: false ~/.claude/settings.json に 1 行追記するだけで解決する。ファイルが存在しない場合は新規作成し、既存の設定がある場合は {} 内に追記する。 1 2 3 { "autoMemoryEnabled": false } これで Memory への自動書き込み・読み込みが停止し、auto-memory 機能全体が無効化される。 影響範囲 機能 autoMemoryEnabled: false にしたときの変化 Memory への自動書き込み・読み込み 停止 CLAUDE.md の読み込み 変化なし（従来どおり動作） Skills に書いたルールの適用 変化なし（従来どおり動作） CLAUDE.md や Skills の設定はそのまま有効なので、プロジェクト固有のルールが失われる心配はない。 ...

Qiita に投稿された「Claude Code を Level 5 まで育てたら、開発が「指示と確認だけ」になった — 実ファイル構成で解説」が大きな反響を呼んでいる。CLAUDE.md・Skills・Hooks・Agents を組み合わせて Claude Code を 5 段階で「育てる」ことで、人間の作業を「指示と確認だけ」に絞り込むアプローチを実ファイル構成とともに解説した記事だ。 「AI にコードを書かせている」と「AI と開発している」は違う Claude Code を導入した当初は、毎回こんなプロンプトを書いていたという： 1 2 3 4 5 UIテキストはハードコーディングしないでください。 src/i18n/ja.ts に追加してから使ってください。 テストも書いてください。 外部リンクには rel="noopener noreferrer" を付けてください。 コミット前に npx astro check と npm test を実行してください。 毎回同じことを書くのは「AI にコードを書かせている」状態であり、「AI と開発している」とは言えない。同氏は 1 か月の試行錯誤を経て、作業は「何を作るか指示する」と「動作確認する」だけになったという。 Claude Code 5 つのレベルの全体像 Level 追加要素 何が自動化されるか 人間がやること 1 素のプロンプト なし 全指示を毎回手打ち 2 + CLAUDE.md プロジェクトルールの自動読み込み ルール違反の指摘が不要に 3 + Skills 手順書のオンデマンド注入 定型作業の手順説明が不要に 4 + Hooks 品質チェックの自動実行 「テスト実行して」が不要に 5 + Agents 並行レビューの自動実行 レビュー依頼が不要に Level 2: CLAUDE.md — 「プロジェクトの憲法」を持たせる プロジェクトルートに CLAUDE.md を置くと、Claude Code が会話開始時に自動で読み込む。これは「プロジェクトの憲法」だ。 ...

東京大学の院生（shunya_sudo）が、45 本の cron ジョブ・36 個のカスタムエージェント・132 本の Python スクリプト で構成した日常業務自動化システムの全記録を Zenn で公開した。M1 冬から約半年間 Claude Code を使い続けて構築したシステムで、メール処理・論文監視・ML コード開発・システム自己監視まで設計原則と実装を網羅している。 システムの全体構成 macOS 上で以下の構成で稼働している。 構成要素 数 cron ジョブ 45 個 カスタムエージェント 36 個 Python スクリプト 132 本 基本アーキテクチャは 「Python が処理、Claude CLI が判断」 というシンプルな分離原則に基づく。データ取得・加工は Python スクリプトが担い、要約・判断・生成を Claude CLI が受け持ち、定時実行は cron で管理する。 主な自動化タスク メール処理（Gmail API） Gmail API を用いてメールを 4 段階に自動分類 し、返信が必要なものには 下書きを自動生成 する。 緊急対応 / 要確認 / 参照 / アーカイブの 4 レベル分類 Claude が文脈を読んで返信の下書きを生成 最終判断・送信は人間が行う 日程調整（ICS URL） ICS URL を活用してカレンダーを自動更新し、日程調整の候補時間を自動挿入する。手動でのカレンダー確認作業をゼロにした。 ...