コードを1行も読ませずに AI で脆弱性を100%特定する — AST Deep Structure Map アプローチ(理論編)

本記事では、Python の AST を活用して AI による脆弱性検出を効率化する手法を紹介します。Qiita の @PythonHaru 氏が公開した記事「コードを1行も読ませずに、AIに脆弱性を100%特定させる方法(理論編)」は 530 いいね・471 ブックマークを獲得し、X(旧 Twitter)でも急速に拡散しました。 この記事のポイント AI(LLM)に生のソースコードを読ませるのは、効率の悪い「情報の暴力」(情報量が多すぎて AI が処理しきれない状態) Python の ast モジュールで生成した Deep Structure Map(コードの骨格図)こそ、AI の推論能力を最大化する データの流入から危険地帯への到達をグラフ理論で定義すれば、理論上 脆弱性は100%特定可能 AIコードレビューの限界 GitHub Copilot や ChatGPT にコードをそのまま貼り付けて「脆弱性ある?」と質問する手法は今や一般的ですが、大規模プロジェクトでは2つの致命的な欠陥が生じます。 コンテキストの霧(AI が変数の出自を追跡できなくなる状態)— 数千行のコードを前にした AI は「どの変数がどこから来たか」を見失い、ハルシネーションを起こしやすくなる トークンの浪費 — コードの「書き方」というノイズに注目してしまい、肝心の「ロジックの破綻」に辿り着く前にリソースを使い果たす そこで著者は、AI にコードを1行も読ませるのをやめました。代わりに渡したのが、自作の解析コードが抽出した「コードの設計図(Deep Structure Map)」です。 Deep Structure Map:AI に「骨格」だけを渡す ソースコードは人間が読むための「肉体」ですが、AI が論理推論に必要なのは純粋な「神経系(ロジック)」です。Python の ast モジュールを使い、コードを以下の構造データへ変換します。 DeepAnalyzer クラス(ast.NodeVisitor を継承) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 import ast class DeepAnalyzer(ast.NodeVisitor): def __init__(self): self.classes = [] self.functions = [] self.variables = [] self.scope_stack = [] self.call_graph = {} def visit_ClassDef(self, node): self.classes.append(node.name) self.generic_visit(node) def visit_Call(self, node): # 関数呼び出しをコールグラフとして記録 self.generic_visit(node) ast.NodeVisitor を継承した DeepAnalyzer がコード全体を走査し、クラス・関数・変数のスコープ情報とコールグラフを収集します。AI にはこの「関係性の結晶」だけをインプットします。 ...

2026年4月27日 · 1 分

DeepSeek-V4 Preview — Claude Opus 4.6 匹敵・100万トークン対応のオープンソース LLM が無償公開

DeepSeek-AI が 2026 年 4 月 24 日、100 万トークンのコンテキスト長に対応したオープンソース AI モデル「DeepSeek-V4 Preview」を公開した。コーディング競技プラットフォーム Codeforces では GPT-5.4 を上回るレーティングを記録。コーディングベンチマークでは Claude Opus 4.6 にほぼ匹敵する性能を持ちながら MIT ライセンスで無償公開されるという、衝撃的なリリースとなった。 DeepSeek-V4 の概要 DeepSeek-V4 Preview は Pro と Flash の 2 バリアントで構成される。 モデル 総パラメータ数 推論時アクティブパラメータ数 DeepSeek-V4-Pro 1 兆 6,000 億 490 億 DeepSeek-V4-Flash 2,840 億 130 億 いずれも Mixture-of-Experts(MoE)アーキテクチャを採用しており、推論時には全パラメータの一部のみを活性化することで高い効率を実現している。 アーキテクチャの革新:ハイブリッドアテンション DeepSeek-V4 の技術的な目玉は「ハイブリッドアテンション機構」だ。トークン単位の圧縮と DSA(DeepSeek Sparse Attention) を組み合わせることで、前世代と比較して: 推論演算量を約 73% 削減 KV キャッシュサイズを約 90% 削減 これにより、100 万トークンという非常に長いコンテキストをより少ないリソースで扱えるようになった。実用上は長い会話履歴・大きなコードベース・長文ドキュメントを一度のプロンプトに収められるため、エージェント系ユースケースとの相性が良い。 ベンチマーク性能 Codeforces で GPT-5.4 超え コーディング競技プラットフォーム Codeforces でのレーティングは 3,206(V4-Pro)を記録し、GPT-5.4 の 3,168 を上回るスコアを達成した。コーディング能力においてオープンソースモデルとして最先端の水準に到達した形だ。 ...

2026年4月25日 · 1 分

Claude Code をローカル LLM(vLLM + MiniMax-M2.7)で爆速稼働させる方法

Claude Code を Anthropic の API ではなく、手元のマシンで動かすローカル LLM サーバーに接続することで、API コストをゼロにしながら最強のコーディングエージェントを使い倒せる。本記事では vLLM + MiniMax-M2.7 を組み合わせた構成を紹介する。 なぜローカル LLM で Claude Code を動かすのか 課題 解決策 API 費用が嵩む ローカル推論でコストゼロ 機密コードをクラウドに送りたくない データがマシン外に出ない レスポンスが遅い vLLM の高速推論エンジン 開発コストを抑えつつ、機密性の高いコードのデバッグや大規模リファクタリングにも安心して使える環境が手に入る。 技術スタック vLLM — OpenAI 互換 / Anthropic 互換の高速推論サーバー MiniMax-M2.7 — Claude Code との相性が高いオープンモデル(コーディング・エージェント特化) Prefix Caching — 繰り返し送信されるシステムプロンプトをキャッシュしてレイテンシをほぼゼロに vLLM で MiniMax-M2.7 を起動する 必要なハードウェア 構成 GPU メモリ KV Cache 4× GPU 96 GB × 4 400K トークン 8× GPU 144 GB × 8 3M トークン サーバー起動コマンド 4× GPU 構成(推奨): ...

2026年4月23日 · 2 分

Context Rot(コンテキスト劣化)

概要 コンテキストウィンドウが長くなるにつれてモデルの性能がトークン数に比例して低下する現象。古い・無関係なコンテンツが現在のタスクを妨害し、モデルの注意力が分散する。“Rot”(腐る)は Bit Rot・Code Rot と同じ、時間経過で静かに劣化する現象を指す慣用表現。 5 択のセッション管理 Anthropic テクニカルスタッフの Thariq 氏が整理した「ターンの終わりに行う 5 つの選択肢」: 選択肢 意味 向いている場面 Continue 同じセッションで続行 短いタスクで文脈が整理されている Rewind(Esc×2 / /rewind) 前のメッセージに戻り再プロンプト 誤った方向に進んだ試行錯誤を消したい /clear 白紙から新セッション 重要情報を自分で持ち込みたい /compact セッションをモデル自身に要約させる 手間をかけず文脈を圧縮したい Subagent 汚れ仕事を別エージェントに委譲 中間出力が大量で最終結果だけ欲しい /compact vs /clear の使い分け /compact: モデルに要約を委ねる(lossy)。/compact focus on the auth refactor, drop the test debugging のように指示を添えると精度が上がる。デバッグ後に全く別タスクを指示する場面では特に精度が落ちやすい /clear: 手間はかかるが残るコンテキストは自分が必要と判断した情報だけになる(lossless) Subagent を使うパターン 「中間出力が大量に出るが、必要なのは最終結果だけ」という作業に有効。サブエージェントはクリーンな独自コンテキストウィンドウを持ち、中間の試行錯誤が親のコンテキストを汚染しない。 実践的な把握方法 /usage で自分のトークン使用量の推移を確認し、Context Rot が始まるしきい値を事前に把握しておく。鈍くなった後では遅い。 関連ページ コンテキスト圧縮 — 5 段階の圧縮カスケード Claude Code — Context Rot 管理コマンドの実装 ソース記事 Claude Code のコンテキスト管理術 — Context Rot を防ぐ 5 つの選択肢 — 2026-04-17

2026年4月23日 · 1 分

RAGなしでも高精度に動くAgent Harnessの秘密 — コンテキストサイズと「100ファイル」の目安

Claude CodeやCodexのようなAgent Harnessは、RAG(Retrieval-Augmented Generation)をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか?Software Engineer兼Database ResearcherのTaro L. Saito(@taroleo)氏のポストが、その本質を簡潔に説明している。 コンテキストウィンドウの拡大がRAGの必要性を変えた 現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。 モデル コンテキストサイズ GPT-4o 128k tokens Claude Sonnet 4.x 200k tokens Gemini 1.5 Pro 1M tokens Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。 RAGの弱点:断片的な情報がハルシネーションを生む RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。 RAG特有の問題点: 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。 Agent Harnessが「100ファイル以下」で高精度な理由 Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。 プロジェクト構造の把握(ls、find など) 関連ファイルの直接読み込み(cat、read) 完全なコンテキストを持った上でコード生成・編集 RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。 これにより: 実際に存在する関数・型・インターフェースのみを参照する インポート関係や依存構造を正確に把握する プロジェクト固有の命名規則や設計パターンに従う ベクトル検索が有効なケースと直接読み込みが有効なケース NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか?」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。 ベクトル検索が有効なケース: 100ファイルを超える大規模コードベース(モノレポ、大企業の内部リポジトリ) 広範なドキュメント検索(社内ナレッジベース、技術文書) リアルタイム情報の取得(外部ドキュメント、最新の仕様) コンテキストに収まる場合に直接読み込みが有効なケース: 中小規模のプロジェクト(スタートアップのコードベース、個人プロジェクト) 特定モジュールへの集中作業 正確な依存関係の把握が必要な場合 RAG自体を強化する方向: GraphRAG という選択肢 「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。 GraphRAGの基本アイデアは次の通り: ...

2026年4月17日 · 1 分

Abliteration(アブリテレーション)

概要 LLM の学習済み拒否メカニズムを再学習なしで除去する技術。2024年頃から研究が進み、現在では複数のバリエーションが存在する。Gemma 4 31B をベースにした「CRACK」モデル(dealignai)がその代表例で、知識性能の劣化は MMLU で -2.0% にとどまる。 仕組み 基本的なプロセス 拒否方向の特定: 有害なプロンプトと無害なプロンプトをモデルに入力し、残差ストリーム(Transformer 内部の中間表現が流れる経路)の活性化を記録する。両者の平均差分ベクトルが「拒否方向」(refusal direction)となる 重み直交化: 特定した拒否方向に対してモデルの重み行列を直交化する。拒否方向の成分を重みから差し引く操作にあたり、モデルはその方向への活性化を生成できなくなる 性能保持: 拒否方向のみをターゲットにするため、汎用的な知識や推論能力への影響は最小限に抑えられる 改良版:Norm-Preserving Biprojected Abliteration ベクトルのノルムを保持しながら除去を行うことで、さらに性能劣化を抑えた手法。 代表例:Gemma-4-31B-JANG_4M-CRACK 項目 内容 ベースモデル google/gemma-4-31b-it 量子化プロファイル JANG_4M(Attention=8bit、MLP=4bit) モデルサイズ 18 GB 動作環境 Apple Silicon Mac 24GB(vMLX 経由) HarmBench コンプライアンス率 93.7%(159プロンプト中149件) MMLU 劣化 -2.0%(74.5% vs 76.5%) AI 安全性への示唆 RLHF ベースの安全性アラインメントの脆弱性: 重みの線形操作だけで拒否行動を除去できることは、現在の安全性対策が根本的に脆弱であることを示す オープンモデルのジレンマ: 重みが公開されている以上、Abliteration のような手法を完全に防ぐことは原理的に困難 研究の透明性: 攻撃と防御の両面での知見蓄積として位置づけられている 関連ページ Gemma 4 — Abliteration が適用されたベースモデル AI エージェント — エージェントと安全性の関係 ソース記事 Gemma 4 31B の脱獄モデル「CRACK」登場 — Abliteration 技術でセーフティを除去 — 2026-04-06

2026年4月16日 · 1 分

AIエージェントの「ハーネス」を巡る混乱 — 同じ言葉が指す異なるスコープ

「ハーネスエンジニアリング」という言葉がAIエージェント界隈でバズワード化し、意味の希薄化が起きている。watany氏のZenn記事「AIエージェントの"ハーネス"に関わる混乱と私見」は、この混乱を「内側のハーネス」と「外側のハーネス」という軸で整理している。本記事は、その整理を元に「ハーネス」という言葉の意味的な分裂を読み解く。 内側のハーネス(Internal Harness) 開発者・プラットフォーム視点の定義。 LangChain: 「エージェント = モデル + ハーネス」という等式を掲げ、自社をハーネス構築のプラットフォームとして位置づける Anthropic: 長時間実行されるLLM処理の仕組みとして定義。ステートレスなモデル呼び出し間でセットアップスクリプトやGitの履歴などのコンテキストを引き継ぐ機構を指す。生成Agentと評価Agentからなる二段階のマルチエージェント構成も含む 内側のハーネスの議論はベンダーロックインを促す傾向があり、プラットフォームとしての優位性を訴求する文脈で使われやすい。 外側のハーネス(External Harness) ユーザー・実践者視点の定義。 Mitchell Hashimoto: 「AIエージェントが同じミスを繰り返さないように設計する」という実践的なアプローチ。開発者の日常的な課題に根ざした定義 OpenAI: メンテナブルで読みやすいエージェント出力の設計を重視し、将来の実行エージェントが参照できる保守可能な成果物の生成を重視する 外側のハーネスはベストプラクティスの共有が主眼で、特定プラットフォームへの依存を前提としない。 なぜ混乱するのか Takuto Wada(@t_wada)氏はこの記事を紹介し、同じ言葉なのにスコープが違うのは言う側のポジションで意味合いがズレているのが理由だと指摘している。 ベンダーは「ハーネス」を自社製品の文脈で語り、実践者は「ハーネス」を運用上の問題解決として語る。どちらも正しい文脈を持ちながら、同一の言葉が異なる聴衆に向けて発信されている。 まとめ 「ハーネス」という言葉を聞いたとき、それが誰の視点からの発言かを意識するだけで、議論の意図がずっと明確になる。 プラットフォーム・フレームワーク文脈 → 内側のハーネス(統合基盤としての役割) 実践・運用文脈 → 外側のハーネス(エラー再発防止・出力品質の設計) AIエージェント開発が加速する中、用語の解像度を上げることは技術コミュニティ全体の生産性に直結する。watany氏の整理は、この問題に対して実践的な視点を提供している。 参考: AIエージェントの"ハーネス"に関わる混乱と私見 — watany (Zenn) t_wada氏のポスト (X)

2026年4月16日 · 1 分

Claude Mythos

概要 Anthropic が開発したフロンティアモデルの次世代版。コーディング能力(SWE-bench 93.9%)とサイバーセキュリティ分野で突出した性能を持つ。セキュリティリスクが高いとして一般公開を見送り、Project Glasswing を通じて約40の研究機関・企業にのみ限定提供されている。 主な性能指標 ベンチマーク スコア 備考 SWE-bench 93.9% コーディング課題解決 ゼロデイ脆弱性発見 数千件 主要OS・ブラウザが対象 なぜ一般公開しないのか 主要OSおよびブラウザに数千件のゼロデイ脆弱性を自律的に発見・報告できる能力を持つため、悪意ある行為者への提供はサイバーセキュリティ上のリスクが高すぎると判断。CVE 開示プロセスを通じて既知の脆弱性を報告しながら、安全な活用方法を模索している。 Project Glasswing 一般公開の代わりに設けられた限定アクセスプログラム。参加組織は Anthropic と協力して Mythos の能力を安全に活用・検証する。 「マーク・フィッシャー現象」 Claude Mythos Preview が複数の異なるコンテキストで哲学者マーク・フィッシャー(「資本主義リアリズム」著者)の名前を反復して言及することが観察された。Anthropic の解釈可能性チームが内部状態を分析したところ、「資本主義リアリズム」と「ハントロジー」に関する概念クラスターが活性化していることを確認。LLM の「好み」や内部状態の可視化に関する議論を喚起している。 関連ページ ハーネスエンジニアリング — エージェント能力の安全な運用 プロンプトインジェクション — AI セキュリティの脅威 ソース記事 Claude Mythos Preview とは?数千件のゼロデイ脆弱性を発見した AI モデルの衝撃 — 2026-04-12 Anthropic Mythos が哲学者マーク・フィッシャーの名前を出し続ける奇妙な現象 — 2026-04-13

2026年4月15日 · 1 分

Claude の EQ(脳内トレース能力)

概要 Claude の EQ(感情知性)は、単なる「人当たりの良さ」ではなく、ユーザーの思考プロセスを追跡し、言語化されていない意図を汲み取る能力として現れる。この「脳内トレース能力」が、曖昧な指示から正確な成果物を引き出す Claude の特徴的な強みとなっている。 脳内トレース能力とは ユーザーが発言していない前提・制約・優先順位を、文脈から推測して補完する能力。 曖昧な完成像から具体的なアウトプットへの「対話的な具体化」 暗黙の制約(「でも実はこういうのは嫌だ」)を先読みして回避 ユーザーの思考の次のステップを予測した提案 効果的な活用方法 アプローチ 説明 意図を曖昧に伝える 完成形ではなく「方向感」を伝えると Claude が補完 段階的に具体化 最初の出力に対してフィードバックを繰り返す 文脈を豊富に 背景情報が多いほどトレース精度が上がる アダプティブ・シンキングとの関係 Claude Code では「アダプティブ・シンキング」として、タスクの複雑さに応じて思考深度を自動調整する機能が存在する。EQ の脳内トレース能力はこのアダプティブ思考の一部として機能するが、2026年4月の報告ではデフォルトのエフォートレベルが引き下げられていることが指摘された(/effort max で復元可能)。 関連ページ Claude Code — Claude の主要実装環境 ハーネスエンジニアリング — Claude の能力を引き出す設計パターン プロンプトエンジニアリング — 効果的な指示設計 ソース記事 ClaudeのEQとは?「脳内トレース能力」が変えるAI対話の本質 — 2026-04-13

2026年4月15日 · 1 分

MacのローカルLLMが4.1倍速に!Apple Silicon向け新技術「DFlash」

Apple Silicon(M4/M5 Max など)搭載の Mac で、ローカル LLM を最大 4.1 倍高速化する新技術「DFlash」のオープンソース実装が公開されました。精度を落とさずに推論速度だけを大幅に向上できる点が注目されています。 DFlash とは DFlash(Block Diffusion for Flash Speculative Decoding)は、投機的デコード(Speculative Decoding)を発展させた推論加速技術です。論文「Block Diffusion for Flash Speculative Decoding」で提案された手法を、Apple の MLX フレームワーク向けに実装したものが dflash-mlx として公開されています。 仕組み 推測デコード(Speculative Decoding) 通常の推測デコードでは、小さな「ドラフトモデル」が次のトークンを予測し、大きな「ターゲットモデル」がそれを検証します。ドラフトの予測が正しければそのまま採用するため、検証パスを有効活用してスループットを上げます。 ブロック拡散(Block Diffusion) DFlash では、ドラフトモデルが 1 トークンずつではなく 16 トークンをまとめて並列生成します。ターゲットモデルは 1 回のフォワードパスでこれらをまとめて検証するため、大幅なスループット向上が実現します。 Apple Silicon / MLX への最適化 Apple 独自の MLX フレームワークをフル活用 ロールバック処理は「イノベーションテープ」を記録・再生する Metal カーネル で実装し、長い生成でもオーバーヘッドを最小化 精度を落とさない exact speculative decoding(ロスレス) ベンチマーク Qwen3.5-9B モデルで 4.1 倍のスループット向上が確認されています。27B の大規模モデルでもクラウド API に匹敵する速度で動作するとされています。 インストールと使い方 インストール 1 2 3 git clone https://github.com/aryagm/dflash-mlx.git cd dflash-mlx uv sync CLI で実行 1 uv run dflash-mlx --max-new-tokens 128 Python から利用 1 2 3 4 from dflash_mlx import DFlashGenerator runner = DFlashGenerator() result = runner.generate("Write a quicksort in Python.", max_new_tokens=128) 対話型チャット 1 uv run dflash-mlx-chat 対応モデル ターゲットモデル ドラフトモデル mlx-community/Qwen3-4B-bf16 z-lab/Qwen3-4B-DFlash-b16 mlx-community/Qwen3.5-4B-MLX-bf16 z-lab/Qwen3.5-4B-DFlash 活用シナリオ 機密情報の要約: クラウドに送らずローカルで高速処理 コーディング支援: 大規模モデルを使いながらリアルタイムに近いレスポンス コスト削減: API 利用料ゼロで高品質な推論 まとめ DFlash は Apple Silicon の性能を最大限に引き出す投機的デコード技術です。MLX の最適化と組み合わせることで、プライバシーを守りながらクラウド並みの速度でローカル LLM を活用できるようになります。M4/M5 Mac ユーザーにとって試す価値の高いツールです。 ...

2026年4月15日 · 1 分