CodexについにSkillsが来たので徹底解説 先日のアップデートでようやくCodexにも待望のSkillsが実装された。この機能を待ち望んでいた方も多いのではないだろうか。今回はこのSkillsをまだ活用していない方に向けて仕組みと利用例を徹底解説している。ぜひ参考にしていただけたら嬉しい。 ちなみにSkillsはCodex特有の仕組みではなく、もともとClaude Codeで実装されていた概念で、エージェントが動的に発見・ロードできる、指示・スクリプト・リソースのパッケージだ。「ナレッジの目次だけ最初にLLMに渡して、本当に必要な時だけ中身を読み込む」仕組み。コンテキストエンジニアリングの一環として位置づけられる。 一言で言うと 個人的な解釈だと、Skillsは必要な時にLLMの判断で自動的に読み込まれるカスタムコマンドに近い。 ただ、その説明だけでは「で、それの何が便利なの?」とい

🌟 はじめに:AIエージェント時代のワークフローと「理想と現実のギャップ」 LLMの台頭により、システム開発の現場では「AIエージェント」をどのように業務や自社製品に組み込むかが喫緊の関心事となっています。 一方で、いざプロダクション環境でエージェントを動かそうとすると、既存のツールと要件の間に 「理想と現実のギャップ」 を感じることはないでしょうか? 「自律的に動くエージェントは魅力的だが、本番環境では挙動を制御したい」 「SuperAgentの挙動が不安定なので挙動を把握したい」 「多数のエージェントタスクの並列処理やHuman-in-the-Loop(HITL)、長時間走るコストの高いタスクの再開処理(checkpoint/resume)がうまく扱えない」本記事では、こうした課題意識から開発している新しいオーケストレーションエンジン 「Graflow」 の設計について解説します

When I askedChatGPT whatit remembered about me,it listed 33 facts from my name and careergoals to my current fitness routine. But how doesit actually store and retrieve this information? And why doesit feel so seamless? After extensive experimentation, I discovered thatChatGPT’s memory system is farsimpler than I expected. No vectordatabases. No RAG over conversation history. Instead,it
導入 こんにちは、株式会社ナレッジセンスの須藤英寿です。 今回は、非構造データから構造データとナレッジグラフを構成して、質問に応じた検索手法を実行することで高い精度を実現する手法「BookRAG」を紹介します。 サマリー RAGはこれまでチャンク化した文書を検索するや、ナレッジグラフを構築して検索する手法など様々な手法が提案されて来ましたが、それぞれ苦手な検索(詳細は後述の課題意識で説明)が存在し精度に限界がありました。 「BookRAG」はツリー構造データとナレッジグラフを組み合わせたうえで、検索に利用可能な処理を11種類作成し、検索時に適切な処理を選択することで高い精度を実現できる手法となっています。 課題意識 既存手法の課題 RAGはこれまで様々な手法が提案されてきましたが、苦手な検索も存在します。 一般的なチャンク化した文書を検索するRAGでは、離れた場所の内容同士の関係性を捉える

© LayerX Inc. 3 LLMとRAG • LLMの制限 ◦ 学習時点で知識が止まっている(カットオフ) ◦ 社内用語や特定ドメインの専門知識がない ◦ 嘘(ハルシネーション)をつく可能性がある • RAG(Retrieval-Augmented Generation) ◦ 外部知識ベースから関連⽂書を検索し、LLMに最新のコンテキストを提供する ◦ リアルタイムで取得された情報を活⽤することで、正確で信頼性の⾼い回答を実現 LLMの制限とRAG © LayerX Inc. 4 LLMとRAG • 従来のRAGの仕組み ◦ ドキュメントをチャンク化し、Embedding(埋め込みベクトル)の類似度で検索する • 弱点 ◦ グローバルな意味構築ができない ▪ 上位数件の情報を取得して回答するため、ドキュメント全体を通して何が⾔えるか?と いう質問に答えられない • 例:「過去10年間

この記事は 実践で フルAI コーディングするための考え方とノウハウを凝縮したものです。筆者が持ってるノウハウはほぼ全て書いたつもりです。 Algomatic アドベントカレンダー 12/8 です。 この記事は、必要となる前提知識・考え方と、実践ノウハウと、AI デトックスについての三段構成になっています。 注意事項: この記事は、実践で、本格的なプロダクト開発をフルAI コーディングするためのものです つまり、メンテナンス性がとても重要です フルAI コーディングとは、コーディングエージェントなどのAI のみでコーディングすることです。一部人間がちょっとした手直しをすることもあるかもしれませんが、基本的にはAI に書かせます LLM とは何かを知ってる人向けの記事です Claude Code や Codex や gemini-cli などをコーディングエージェントと呼ぶことを知

We gave Claude the ability to fine-tune language models using a new tool called Hugging Face Skills. Notjust write training scripts, but to actually submit jobs to cloudGPUs, monitor progress, and push finished models to the Hugging Face Hub. This tutorial shows you howit works and how to useit yourself. Claude Code can use "skills"—packaged instructions, scripts, anddomain knowledge—to accom
Previous slideNext slideToggle fullscreenOpen presenter view LLM勉強会 基礎からエージェント設計まで Tomoki Yoshida (birder)️ DeNAAI技術開発部AIイノベーショングループ 2025-12-01 (月) 13:00-16:00 みなさんの3時間絶対に無駄にしません!本気で準備しました! どうか今日だけは内職ご遠慮ください 今日の流れ イントロダクション 前半 知識 実践演習(ハンズオン) 後半 知識 実践演習(ハンズオン) 案件の実例紹介 → 詳細時間配分 イントロダクションSlackでぜひ盛り上がってください! こんなこと思ったことありませんか? 難しいタスクのプロンプトをチューニングしているけどうまくいかない Web版Gemini/ChatGPTとAPI実装時の差分がわからないので、Web
2025.12.05 イベントレポートAIエンジニアが本気で作ったLLM勉強会資料を大公開 〜そのまま使えるハンズオン用コード付き〜 by Tomoki Yoshida #ai #llm #rag はじめに こんにちは、2020年に新卒入社してからDeNAでAIエンジニアをしている吉田( @birdwatcherYT )です。 いつもは Qiita に技術記事を発信しているのですが、今回は社内の取り組みとしてエンジニアリングブログを書くことにしました(入社6年目でなにげに初執筆です)。 それでは、2025年12月1日に渋谷オフィスでのオフライン開催とオンラインのハイブリッド形式で開催した社内勉強会の開催レポートをお届けします。 3時間の講義&ハンズオン形式のLLM勉強会を実施 新規AIプロダクトを開発しているPdM&エンジニア向けに、AIをコアとしたプロダクト作りのために必要な知識を詰め

はじめにChatGPTやGeminiに搭載されているDeepResearchなどの「深掘り調査」ができるAIエージェントって便利ですよね。ただ、エンジニアとしては「深掘り回数を変えたり検索対象を限定したりともっと挙動を制御したい」という欲求が出てきます。そこで今回は、Googleの Agent Development Kit (ADK) を使用して、独自のDeep Researchアプリを作成しました。 実装してみた結果得られた、ADKならではのメリットや、エージェント設計の「深さ」に関する知見を共有します。 作成したアプリの画面 作成したアプリのコードは以下にありますので、ぜひお手元でお試しください💡 なぜ今、ADKで自作するのか? 1.Google検索という「最強の武器」が標準装備 Deep Research系のタスクにおいて、命綱となるのは「検索品質」です。どんなに賢いLLMを

※ 凡例: ✓ = 明示的に言及、(言及) = 関連概念として触れられている、- = 言及なし ※ Reflection/Critic の Anthropic 列については、記事内で「自己批評的なループ」として触れられている Evaluator-Optimizer の概念を対応付けたもの。 ※ LangGraph 列については、引用ページ [2:1] だけでなく、ReAct エージェントや Plan-and-Execute チュートリアルなど LangGraph ドキュメント全体を含めて対応付けている。 ※ Evaluator-Optimizer は Reflection の一種とも捉えられるが、Anthropic が重視しているため独立して記載した。両者の違いは以下の通り: Reflection/Critic: 同一の LLM が自らの出力を批評し、定性的に改善する(自己批評) Eval

リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く