2026-08-27 のダイジェスト

zenn.dev 62日前

MCPゲートウェイ「Manifold」にOPAサイドカーでツール単位の認可機能を追加した

MCPゲートウェイManifoldに、OPAサイドカーを用いたツール単位の認可機能を追加。ManifoldはPEP(強制のみ)、OPAはPDP(Rego judgeによる許可判定)として役割を分離し、tools/callは呼び出しごとに判定、tools/listは許可ツールのみに絞り込む。判定不能時は全て拒否するfail-closed設計を採用し、ポリシー作成者向け全ツールカタログAPIやテナント単位のバイパスヘッダーも実装。接続可否を扱う標準仕様EMA(Enterprise-Managed Authorization)とは効くレイヤーが異なり(EMA=サーバー単位・接続時、Manifold+OPA=ツール単位・リクエスト時)、両者は補完関係にあると位置づけている。

MCPゲートウェイManifoldに、OPAサイドカーを用いたツール単位の認可機能を追加。ManifoldはPEP(強制のみ)、OPAはPDP(Rego judgeによる許可判定)として役割を分離し、tools/callは呼び出しごとに判定、tools/listは許可ツールのみに絞り込む。判定不能時は全て拒否するfail-closed設計を採用し、ポリシー作成者向け全ツールカタログAPIやテナント単位のバイパスヘッダーも実装。接続可否を扱う標準仕様EMA(Enterprise-Managed Authorization)とは効くレイヤーが異なり(EMA=サーバー単位・接続時、Manifold+OPA=ツール単位・リクエスト時)、両者は補完関係にあると位置づけている。
↗ 元記事を開く
www.percona.com 62日前

ベクトルインデックスのベンチマーク

ベクトル検索インデックスのベンチマーク手法を解説する記事。HNSWとIVFの仕組み、recallとthroughputはセットで測る必要があること、ef_searchやM等のパラメータがトレードオフを生むこと、インデックスが使われず暗黙にフルスキャンへフォールバックする落とし穴、ビルド方式(incremental/bulk)の違いやフィルタ検索での正しいground truthの取り方など、公平な比較のために必要な計測設計と実装時に踏んだ落とし穴を詳細に説明している。

ベクトル検索インデックスのベンチマーク手法を解説する記事。HNSWとIVFの仕組み、recallとthroughputはセットで測る必要があること、ef_searchやM等のパラメータがトレードオフを生むこと、インデックスが使われず暗黙にフルスキャンへフォールバックする落とし穴、ビルド方式(incremental/bulk)の違いやフィルタ検索での正しいground truthの取り方など、公平な比較のために必要な計測設計と実装時に踏んだ落とし穴を詳細に説明している。
↗ 元記事を開く
future-architect.github.io 62日前

AIを使ったナレッジ中心設計を試してみた | フューチャー技術ブログ

Go製Webフレームワーク「Popcorn Web」を作りつつ、AIエージェント向けのナレッジ中心設計手法を実践した記事。GoogleのOKF(Open Knowledge Format)を参考に、設計情報をobjective/concept/interfaceなどの型に分類しYAML中心のMarkdownで細分化して管理するスキルを自作。ソースコードではなくナレッジをSSoTとし、AIがそこから実装・フィードバックを行うワークフローを構築した。popcornweb/tinybind-go/tinygodriverの3リポジトリに分けて開発し、リポジトリ間の連携は提案書をAIに作らせて相手側ナレッジに評価させる方式を採用。あえて同じモデルを対立させることで設計を洗練させる効果があった一方、過去の決定記録は言い合いの火種になりノイズだったと述べている。

Go製Webフレームワーク「Popcorn Web」を作りつつ、AIエージェント向けのナレッジ中心設計手法を実践した記事。GoogleのOKF(Open Knowledge Format)を参考に、設計情報をobjective/concept/interfaceなどの型に分類しYAML中心のMarkdownで細分化して管理するスキルを自作。ソースコードではなくナレッジをSSoTとし、AIがそこから実装・フィードバックを行うワークフローを構築した。popcornweb/tinybind-go/tinygodriverの3リポジトリに分けて開発し、リポジトリ間の連携は提案書をAIに作らせて相手側ナレッジに評価させる方式を採用。あえて同じモデルを対立させることで設計を洗練させる効果があった一方、過去の決定記録は言い合いの火種になりノイズだったと述べている。
↗ 元記事を開く
qiita.com 62日前

ClaudeCode のセキュリティ監視ダッシュボードを作ってみた -- 自分を信用しないための個人ツール - Qiita

ClaudeCodeを日常的に使う中で、複数セッションの停止状況を見落としたり、作業許諾を確認せず承認してしまう癖がついた反省から、自分自身を信用しないための個人用セキュリティ監視ダッシュボードを作成した記事。

ClaudeCodeを日常的に使う中で、複数セッションの停止状況を見落としたり、作業許諾を確認せず承認してしまう癖がついた反省から、自分自身を信用しないための個人用セキュリティ監視ダッシュボードを作成した記事。
↗ 元記事を開く
zenn.dev 62日前

issue と pull request のつながりをグラフで描く gh 拡張を作りました

issueを幹にpull requestを枝先へぶら下げてタスク全体像をグラフ表示するGitHub CLI拡張gh-issue-graphの紹介記事。gh api graphql経由でトークンを外部に出さずサードパーティ依存なしで実装されており、closes/refs/推測の3種類の線でissueとPRの紐付けの確からしさを描き分ける。assigned/authored/mentioned/to reviewでの検索、sub-issueツリーの畳み込み、本文をその場で読めるパネル表示、閉じ忘れ回収バッジ(wrap up)や着手可能issueバッジ(ready)などの機能を備える。gh-pr-graphからアイデアを得て作られた。

issueを幹にpull requestを枝先へぶら下げてタスク全体像をグラフ表示するGitHub CLI拡張gh-issue-graphの紹介記事。gh api graphql経由でトークンを外部に出さずサードパーティ依存なしで実装されており、closes/refs/推測の3種類の線でissueとPRの紐付けの確からしさを描き分ける。assigned/authored/mentioned/to reviewでの検索、sub-issueツリーの畳み込み、本文をその場で読めるパネル表示、閉じ忘れ回収バッジ(wrap up)や着手可能issueバッジ(ready)などの機能を備える。gh-pr-graphからアイデアを得て作られた。
↗ 元記事を開く
eng-blog.iij.ad.jp 62日前

「気づいたら夢中になっていた」を、意図してつくる ― ワークショップデザインの舞台裏

本文取得に失敗しナビゲーション情報のみが得られたため詳細不明。タイトルから、参加者が自然と夢中になる状態を意図的に設計するワークショップデザインの手法や舞台裏を紹介するIIJ Engineers Blogの記事と推測される。

本文取得に失敗しナビゲーション情報のみが得られたため詳細不明。タイトルから、参加者が自然と夢中になる状態を意図的に設計するワークショップデザインの手法や舞台裏を紹介するIIJ Engineers Blogの記事と推測される。
↗ 元記事を開く
tech.asoview.co.jp 62日前

AIに任せるほど、顧客が近くなる

アソビューCTOが、AIによって開発コストが下がる中でエンジニアリングのボトルネックが「作れるか」から「何を検証しプロダクトに残すか」へ移動していると論じる記事。社内の座席指定チケットシステム連携事例では、担当エンジニアがAIに技術実装を任せてPdM・デザイナー・マーケ領域を主体的に担い、数年放置されていた案件を2〜3営業日でリリースした。一方、宿泊・レジャー業界の人手不足という市場背景も紹介し、AIに代替できない「顧客の本当の課題を掴む力」の重要性を強調。AIを活かす組織には承認権限の分散・自動検証・現場の一次情報を渡す仕組みと、職種の垣根を越える文化的土台が必要だと結論づけている。

アソビューCTOが、AIによって開発コストが下がる中でエンジニアリングのボトルネックが「作れるか」から「何を検証しプロダクトに残すか」へ移動していると論じる記事。社内の座席指定チケットシステム連携事例では、担当エンジニアがAIに技術実装を任せてPdM・デザイナー・マーケ領域を主体的に担い、数年放置されていた案件を2〜3営業日でリリースした。一方、宿泊・レジャー業界の人手不足という市場背景も紹介し、AIに代替できない「顧客の本当の課題を掴む力」の重要性を強調。AIを活かす組織には承認権限の分散・自動検証・現場の一次情報を渡す仕組みと、職種の垣根を越える文化的土台が必要だと結論づけている。
↗ 元記事を開く
thinkit.co.jp 62日前

エージェントに渡す鍵を、どこまで絞れているか――「GitLab 19.3」がSecrets ManagerとAIゲートウェイで制御を取り戻す

GitLab 19.3では、AIエージェント型ワークロードに対する制御機能を強化。GitLab Dedicated向けAIゲートウェイでデータ所在地・分離ルールをエージェントにも適用し、GitLab Secrets Managerをリミテッド提供してCIシークレットの適用範囲を細かく設定可能にした(Kubernetes/Terraform/OpenTofu対応追加)。さらにSAST検出結果の一括誤検出判定・一括修正、自然言語でフローを生成するFlow Creatorエージェント、GitLabクレジットの利用上限機能、グループ単位のカスタムエージェント公開範囲制限も提供する。エージェントの高速化に加え、権限・コスト・データ所在地の制御を強めた点が特徴。

GitLab 19.3では、AIエージェント型ワークロードに対する制御機能を強化。GitLab Dedicated向けAIゲートウェイでデータ所在地・分離ルールをエージェントにも適用し、GitLab Secrets Managerをリミテッド提供してCIシークレットの適用範囲を細かく設定可能にした(Kubernetes/Terraform/OpenTofu対応追加)。さらにSAST検出結果の一括誤検出判定・一括修正、自然言語でフローを生成するFlow Creatorエージェント、GitLabクレジットの利用上限機能、グループ単位のカスタムエージェント公開範囲制限も提供する。エージェントの高速化に加え、権限・コスト・データ所在地の制御を強めた点が特徴。
↗ 元記事を開く
www.publickey1.jp 62日前

MCPの新ロードマップ公開、今後はAIエージェント対応、HTTP通信への統一、アイデンティティ、よりよいデベロッパー体験などに注力

Linux Foundation傘下のAgentic AI Foundation(AAIF)がMCP(Model Context Protocol)の新ロードマップを発表した。今後はAIエージェント向けメッセージング機能の強化、通信方式のHTTPネイティブへの統一、AIエージェント自身のアイデンティティ管理とエンタープライズ向けセキュリティの実装、ツール呼び出し・発見の簡素化、SDKの開発者体験改善の5分野に注力する方針。

Linux Foundation傘下のAgentic AI Foundation(AAIF)がMCP(Model Context Protocol)の新ロードマップを発表した。今後はAIエージェント向けメッセージング機能の強化、通信方式のHTTPネイティブへの統一、AIエージェント自身のアイデンティティ管理とエンタープライズ向けセキュリティの実装、ツール呼び出し・発見の簡素化、SDKの開発者体験改善の5分野に注力する方針。
↗ 元記事を開く