はじめに 「Agentic Coding　生成AI時代のシステム開発入門」という本を出すくらいなのでAIエージェントのハーネスには興味があって、1週間ほど調査した結果、「ハーネス」の見え方が固まりつつあるので、表題についてラフに書き留めておきます。根拠があるものないものがあるので話半分に読んでください。 スライドの形式で読みたい人はこのスライドの30Pまでくらいを読むと、本記事に近い知見を得られます。 1. ハーネスという言葉への混乱 最近、AI Agent関連のドキュメントやブログで「エージェントハーネス」「ハーネスエンジニアリング」という言葉がよく出てきます。言葉がそれぞれ指す概念が曖昧かつズレている場合がちらほらあり、バズワードなのかなと感じてしまうのが最近の悩みです。 内部ハーネスと外部ハーネス コーディングエージェントユーザ視点でのmartinfowlerのハーネスの記事があって

An open-source, community-driven dependency manager for AI agents. Think package.json, requirements.txt, or Cargo.toml — but for AI agent configuration. GitHub Copilot · Claude Code · Cursor · OpenCode · Codex Documentation · Quick Start · CLI Reference Portable by manifest. Secure by default. Governed by policy. One file describes every agent's context; one command reproduces it everywhere; one p

1830年頃、わずかな夜の明かりを得るためには、約3時間の労働が必要でした。しかし1992年ごろにはそれが1秒にも満たない労働ですむようになったと言われています。ロウソクから白熱電球、蛍光灯へという技術的発展が、光を劇的に安くしたのです。 そうして光が安くなったとき、人は同じ量の光を単に安く買って終わり――ということにはなりませんでした。 人々は、かつて置こうとも思わなかった場所にまで光を置き、街路、工場、看板といった、社会のあらゆる場所に安くなった光を敷き詰めていきました。そうして、工場は曇りや雨の日にも稼働することができるようになったり、深夜営業や夜の読書といった新しい活動が可能になったのです。 そこで儲けたのは、光を提供した会社だけではなく、それをうまく使った会社でした。 では、ソフトウェアや知能が安くなったとき、私たちはそれをどのように使うのでしょうか。 生成AIによる大きな変化は

iOS 26で登場した、「ショートカット」のApple Intelligenceのアクション 病院の明細や荷物の送り状、買い物のレシートや領収書など、デジタル化が進んだ現代でも、まだ紙で受け取るものは少なくありません。きちんと保存している人もいる一方で、つい山積みにしてしまったり、受け取ってすぐ、あるいは一定期間が過ぎたあとに処分してしまったりする人も多いのではないでしょうか。 しかし、そのようにしていると、ふと「あれ、どこの病院だっけ？ いつ送ったんだっけ？ いくらだったっけ？」と思ったときに、確認に時間がかかったり、処分してしまってわからなくなることがあります。とはいえ、こうした事態を避けるために、紙の情報をいちいち書き留めたり、デジタル化して保存したりするのは面倒です。 そこでおすすめしたいのが、Apple Intelligenceの活用です。iPhoneに標準搭載されている「ショー

本記事では、RAGの性能を高めるための「WriteBack-RAG」という手法について、ざっくり理解します。 株式会社ナレッジセンスは、生成AIやRAGを使ったプロダクトを、エンタープライズ企業向けに開発しているスタートアップです。 この記事は何 この記事は、RAGのナレッジベース自体をAIで書き直すことで精度を上げる手法「WriteBack-RAG」の論文[1]について、日本語で簡単にまとめたものです。 今回も「そもそもRAGとは？」については、知っている前提で進みます。確認する場合は、こちらの記事もご参考下さい。 本題 ざっくりサマリー 「WriteBack-RAG」は、RAGの回答精度を高めるための新しい手法です。 北京大学・ジョージア工科大学・清華大学の研究者らによって2026年3月に提案されました。 最近、「AIでナレッジを管理する」というコンセプトが盛り上がっています。 「AI

https://aid.connpass.com/event/386203/

マークダウンを一箇所に集める LLMとMarkdownの相性が良いという話は、最近多くの人が話題にしたり感じていることかと思います。 おそらく、そのうちあらゆるデータを直接LLMに手軽に安く入力できるようになるとは思いますが、それにはしばらく時間がかかるのも確かだと思います。なので、今はとにかくMarkdownを集めてLLMの手に届く範囲に置いておきたくなるわけです。 しかしながら、データというのは、だいたい色々な形式で色々な場所に散在しているものです。なので、そういったデータを変換してまとめる仕組みが一番重要になってきます。逆に言えば、そういう仕組みさえ構築できれば、プラットフォームは、はてなブログでもZennでもTwitterでもNotionでも何でも良かったりします。ただ、データを手軽に取得（APIで取得 or エクスポート）する方法があることが重要ですね。Obsidianが、最近L

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Claude Codeを毎日使っていると、ふと「こいつ、俺のことわかってきたな」と感じる瞬間があります。 先日、DB分析の相談をしたとき、Claude Codeが黙ってソースコードを開いてフラグの意味を確認し始めました。以前は何度もスキーマだけで推測して間違えていたのに、今回は何も言わなくても自分から確認している。 あるいは、テックブログの下書きで「不可欠です」みたいなAI臭い表現が一切出てこなくなった。以前は毎回指摘していたのに。 しれっと変わっている。メモリに保存しただけでは、ここまで行動は変わりません。裏側には、ちょっとした仕組みがあります。 ここでいう「学習」は、知識を覚えさせる話ではありません。Claude Codeの思考パターンや判断の癖を、どう進化させるかという話です。 この記事では、Claude Codeを「使うたびに賢くなるAI」にするために実装した3層の学習構造について

10年分のテーブルが積み重なっています。正直、全テーブルを把握している人は社内に誰もいません。 こういうシーンを想像してみてください。 CSチームから「この会員さん、アプリ上では返却済みになってるんですけど、倉庫側で本当に返却確認できてますか？」という問い合わせが来ました。 これ、調査するのに何が必要かわかりますか？ まず、アプリ側の返却ステータスは aircloset スキーマの配送オーダーテーブルにあります。配送ステータスが「RETURNED」なら「返却済み」。ここまではわかる人もいるかもしれない。 でも、倉庫側の返却確認は bridge スキーマにあります。荷受記録テーブルのステータスが「COMPLETE」であることが「倉庫で実際に荷受処理が完了した」ことを意味する。 問題はこの2つが 別のデータベース にあること。直接のFKは存在しません。つなぐには、間に倉庫連携テーブルがあって、

これらは全て TypeScript で実装され、Pulumi で GCP にデプロイされ、Google OAuth で認証されています。 設計思想 なぜこんなに分けたのか 1つの巨大な MCP サーバーに全機能を詰め込むこともできますが、あえてサーバーを分けています。理由は： 認証スコープの分離 — GWSサーバーにはWorkspace APIのスコープが必要だが、DBクエリサーバーには不要。スコープを最小限にすることで権限の暴発を防ぐ デプロイ独立性 — Grafanaサーバーの変更がDBクエリに影響しない。障害の爆発半径を小さくする ユーザーごとの選択 — エンジニアは全部入れるが、マーケチームはGWSだけ、のように必要なものだけ .mcp.json に追加すればいい 共通基盤 全サーバーに共通するパターンがあります。 認証: 共通パッケージで Google OAuth 2.0 + P

はじめに こんにちは！サロンスタッフ予約サービス「minimo」でエンジニアをしている Nozomuts です。 個人的に GitHub Copilot（以降: Copilot）にとてもお世話になっているので、自分なりの設定や良いなと思っている点をメモとしてまとめてみました！（2026/4 時点） 長めの記事なので、気になるところから拾い読みしてもらえればと思います。 基本的なことも多いですが、どなたかの参考になれば嬉しいです！ 要約 いまの GitHub Copilot は、補完やチャットだけでなく、VS Code、CLI、Copilot cloud agent、Code Review、Spaces まで含む広い構成になっています。 この記事では、Copilot の全体像を整理したうえで、自分が実際に効いていると感じている VS Code 設定、CLI の使い分け、Copilot clo

はじめにUbie株式会社でプロダクトマネージャー（PdM）を務めている、田口（@guchey）です。 この記事では、Claude Codeのプラグインを活用して、プロダクトの指標変動を自動診断する「分析エージェント」を構築した知見を共有します。具体的には、「プロジェクトAのCVR（コンバージョン率）が下がっているんだけど、なぜ？」と一言投げかけるだけで、原因特定からレポート出力までを完遂するシステムを作りました。 実はこの分析エージェント、最初は「Text-to-SQL」の仕組みから着手したのですが、運用するなかで大きな壁にぶつかりました。本当に必要だったのは、自然言語からSQLを書く能力そのものではなく、「なぜ」を問うための膨大な文脈（コンテキスト）をAIに与える仕組みだったのです。 OpenAIが社内データエージェントの構築記（Inside OpenAI's in-house data

予想してみてください。CUSTはCustomer（顧客）でしょう。IDはそのままID。ですが、末尾のXは何を指すのか、さっぱりわかりません。 次に、一般的なAI移行ツールによって「現代化」された後のコードを見てみましょう。 名前はそのまま、スネークケース（snake_case）になっただけ。相変わらず意味不明です。業界ではこれを 「Py-BOL」 と呼びます。モダンな環境で動作し、中身はCOBOLの思考回路のままのPythonコードのことです。コンパイルも通るし実行もできます。しかし、保守性は絶望的です。 私はこの問題を解決するシステムを構築しました。 誰も語らない「3兆ドル」の問題 1959年に設計されたCOBOL（Common Business-Oriented Language）は、現在も1日あたり推定3兆ドルの金融取引を処理しています。ATM取引の約95%、クレジットカード決済の8

はじめに クラシルで開発マネージャーをしているfunzinです。 本記事では、Claude Codeのスケジューラー機能を使って定常業務を自動化し、タスクを覚えておくストレスをゼロに近づける運用フローを紹介します。EM・PM・データ分析担当者など、定常作業を抱えるすべての方を対象にしています。Desktop スケジューラーで自動化を育て、安定したらCloud スケジューラーに昇格させるアプローチが実用的だったので、その運用方法を共有します 導入の背景 毎日こなす定常作業が、以下のように存在していました。 1on1の事前準備: メンバーのSlack・Notion・GitHubの活動を収集し、1on1で話す内容や成果と改善点を整理する チーム朝会: 朝会で出たアクションアイテムをTODOとしてSlackに投稿 議事録生成: MTG後に議事録を作成し、Notionに格納。Slackに要約を投稿

2025/3/29 19:00 更新 — セクション9「5分で体験するCoDD」を大幅改善。要件定義を平文で渡すだけのフローに変更（codd init --requirements spec.md）。フロントマターもwave_configも全自動生成。 この記事はいつもと毛色が違う。体験記ではなく論考だ。 AI開発の方法論がこの2年で3回変わった。プロンプトエンジニアリング、コンテキストエンジニアリング、ハーネスエンジニアリング。オレは全部リアルタイムで通過してきた。AI部下10人を戦国軍団で運用しながら。 で、3つ全部やった先に、誰も解いていない問題があった。 それを解くツールを作った。pip install codd-dev で公開した。結果、クライアント案件のLMSで要件と制約だけ渡して、設計書18本・全コード・全テストをAIに生成させた。 途中で設計判断が変わっても、壊れなかった。

0. 元にした記事・リポジトリ 日本マイクロソフトの Kazuki Ota さんによる 図形フル活用の PowerPoint を GitHub Copilot に読ませてみた https://github.com/runceel/github-copilot-excel-lab を自分の環境で実行してみたところ、動作させる際に詰まる点がいくつかあったので、備忘録として記載する また、GitHub Copilot がどのような処理を行うことで曼荼羅のような複雑な図形を Mermaid に変換しているのかを確認する 1. 環境構築 自分のローカルの WSL には dotnet の実行環境が無かったため、以下の手順で環境構築を行った https://code.visualstudio.com/docs/devcontainers/containers に記載されている手順で Docker と拡張

環境設定から並列セッションでのスケーリングまで、Claude Code を最大限に活用するためのヒントとパターン。 Claude Code は agentic coding 環境です。質問に答えて待つチャットボットとは異なり、Claude Code はファイルを読み取り、コマンドを実行し、変更を加え、あなたが見守ったり、方向を変えたり、完全に任せたりしながら、自律的に問題を解決できます。 これはあなたの作業方法を変えます。自分でコードを書いて Claude にレビューしてもらう代わりに、やりたいことを説明すると Claude がそれをどのように構築するかを考え出します。Claude は探索し、計画し、実装します。 しかし、この自律性にも学習曲線があります。Claude は理解する必要がある特定の制約の中で動作します。 このガイドでは、Anthropic の内部チームと、様々なコードベース、

はじめに フクロウラボの渋谷です。 LLM を活用する中で、PDF や Word、PowerPoint などの資料をそのまま扱いづらいと感じたことはないでしょうか。 テキストを抽出すること自体はできても、レイアウトが崩れたり、表や見出しといった文書構造が失われたりすると、内容を十分に活かせないことがあります。LLM の精度を高めるには、単に文字列を取り出すだけでなく、文書の構造をできる限り保ったまま扱うことが重要です。 そこで今回は、この課題の解決に役立つツールとして、Docling（ドックリング） を紹介します。 Docling とは？ Docling は、IBM Research Zurich 発のオープンソース文書変換ライブラリです。PDF や Word、PowerPoint などの文書を、構造を保ったまま Markdown や JSON などの形式に変換できます。 単なるテキスト抽