Épisodes

  • 株式会社ずんだもん技術室AI放送局 podcast 20251002

    株式会社ずんだもん技術室AI放送局 podcast 20251002
    Oct 1 2025
    youtube版(スライド付き) 関連リンク 未だにAIを「統計的に次の単語を予測しているに過ぎない」って言ってる人いる AIの動作原理に関する議論：単なる「次の単語予測」を超えて この記事では、最新のAI、特に大規模言語モデル（LLM）の能力を「統計的に次の単語を予測しているに過ぎない」と解釈することへの疑問が提起されています。筆者は、この認識では現在のAIが示す高度な成果（まるで意味を理解し、推論しているかのような振る舞い）を説明しきれないと感じています。 AI自身の説明と本質 筆者がAI自身にその仕組みを尋ねたところ、「言語と世界知識を統計的に圧縮した汎用パターン認識器」や、「次に来る単語を予測するために、言語と世界知識を高次元ベクトル空間に圧縮し、そこから最適な次語を取り出すパターン認識器」という回答が得られました。これは、単なる「予測変換」とは異なり、膨大な情報を高次元の空間で効率的に処理し、その結果として人間らしい応答や推論に近い能力を発揮していることを示唆しています。 「統計的予測」という言葉の裏側 「統計的に次の単語を予測する」という表現は、AIの基本的な動作原理を指しますが、その言葉だけを聞くと、まるで単純な辞書引きや確率計算のように誤解されがちです。しかし、実際のLLMは、私たちが話す言葉や世界の知識を数値データ（ベクトル）として「高次元ベクトル空間」に配置し、その膨大なデータのパターンから最も適切な応答を生成しています。この複雑なプロセスによって、AIは文脈を理解し、質問に答え、時にはクリエイティブな文章を生み出すことが可能になっているのです。 新人エンジニアへのメッセージ この議論は、AIの核心的な理解を深める上で非常に重要です。AIが「統計的な予測」に基づいていることは事実ですが、その「統計的な予測」がどのような仕組みで、どれほど複雑な情報処理を経て行われているかを理解することが大切です。 コメント欄でも、「人間も統計的な予測をしているのではないか」「AIに真の推論能力はない」など、様々な視点からの活発な議論が展開されています。これらの多角的な意見に触れることで、AIの可能性と限界、そして人間との違いについて深く考えるきっかけとなるでしょう。 引用元: https://anond.hatelabo.jp/20250930225212 Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code 「Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code（理解負債：LLMが生成するコードの時限爆弾）」というこの記事は、近年のAI、特に大規模言語モデル（LLM）が生成するコードが、開発現場にもたらす新たな課題に警鐘を鳴らしています。 新人エンジニアの皆さんも、もしかしたら「こんなコード、誰が書いたんだろう…」と、過去のレガシーコードの理解に苦しんだ経験があるかもしれません。昔のコードを安全に修正したり、新しい機能を追加したりするには、まずそのコードが「何をしているのか」「なぜそのように実装されているのか」を深く理解する必要があります。これは開発者にとって昔からの課題です。 しかし、LLMの登場により、この「理解の課題」がとてつもない規模で拡大しつつあると著者は指摘します。LLMは驚異的なスピードで大量のコードを生成するため、開発チームは自分たちが書いたわけではない、誰も読んでいないコードを大量に抱え込むリスクに直面しています。著者はこの現象を「理解負債（Comprehension Debt）」と呼んでいます。これは、後からそのコードを理解し、修正するために必要となる追加の時間のことを指します。 品質を重視するチームでは、LLMが生成したコードでも、人間のエンジニアが時間をかけてレビューし、理解し、必要であれば手直ししてからリポジトリにコミットします。これは非常に大切なことですが、結果としてLLMが提供する「高速なコード生成」のメリットが相殺されてしまいがちです。 一方で、スピードを優先するあまり、LLMが生成したコードを十分にレビューせず、また適切なテストも行わずにそのままシステムに組み込んでしまうチームも少なくありません。このような状況が蔓延すると、...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20251001

    株式会社ずんだもん技術室AI放送局 podcast 20251001
    Sep 30 2025
    youtube版(スライド付き) 関連リンク Temporal Workflow で実現する Durable な AI Agent #LayerX_AI_Agent_ブログリレー この記事は、AI Agentを実際のプロダクトに組み込む際に直面する「長時間実行される処理をいかに安定して動かすか」という課題を、Workflow EngineであるTemporal Workflowを使って解決する方法について、新人エンジニアにも分かりやすく解説しています。 AI Agentとは、与えられた目標に対し、ツールを自律的に使って情報を集めたり、環境に働きかけたりしながらタスクをこなすソフトウェアのことです。例えば、ユーザーの入力に応じて情報を検索し、結果を生成するといった一連の処理を「Agent Loop」と呼びます。 このAgent Loopは、数分から数十分かかる長時間処理になることがよくあります。そのため、途中でネットワークが切れたり、サーバーがダウンしたりすると、処理が中断されてしまい、タスクが完了できないという問題が発生します。また、ツールが何らかの変更を伴う場合、中断された処理を単にやり直すと、データが重複して作成されるなどのバグにつながる恐れもあります。 このような問題を解決し、AI Agentの処理を確実に最後まで実行するには、途中で中断されても再開できる「Durable Execution（耐久性のある実行）」を実現する仕組みが必要です。 そこで登場するのが「Temporal Workflow」です。Temporalは、私たちが普段書くようなコードで一連のタスク（Workflow）を定義できる実行エンジンです。AI AgentのAgent Loopにおける「LLM（大規模言語モデル）に処理をさせる」「ツールを実行する」といった個々のステップをTemporalの「Activity」として実行することで、Workflow全体の状態をTemporalが管理し、万が一処理が中断しても、途中から確実に再開できるようになります。 Temporal Workflowを導入することには、いくつかの大きなメリットがあります。 柔軟なタスク実行: AI Agentの処理だけでなく、ファイルアップロード時の前処理や定期実行ジョブなど、様々なバックグラウンドタスクをWorkflowとして組み込めます。外部からの操作に対応: 稼働中のAgentに対して、ユーザーからのメッセージをリアルタイムで受け取ったり（Signalという仕組み）、人の承認が必要なプロセス（Human-in-the-loop: HITL）を簡単に実装したりできます。これにより、ユーザーとの対話がスムーズになります。状態管理の簡素化: Workflowの途中の状態をデータベースなどに明示的に保存する必要がなく、あたかもローカル変数のように扱えるため、開発者は複雑な状態管理に頭を悩ませずに済みます。長時間の待ち状態に対応: 特定の条件が満たされるまで待機したり、排他的に処理を実行したりする機能も標準で備わっており、HITLのような長時間にわたるユーザー操作の待ち受けも安定して行えます。バージョン管理: 長時間実行されるWorkflowの実装が変わっても、古いバージョンと新しいバージョンが混在しないよう、バージョニング機能がサポートされており、安心してデプロイできます。 この記事を通じて、AI Agentをプロダクトで活用するためには、AIや機械学習の専門知識だけでなく、Durable Executionの基盤構築、認証認可、評価、監視など、従来のソフトウェアエンジニアリングにおける多くの挑戦があることがわかります。これらは、新人エンジニアにとっても未来の技術の「当たり前」を共に作り上げる絶好の機会となるでしょう。 引用元: https://zenn.dev/layerx/articles/b5f6cf6e47221e AIエージェントはSaaSをどう変える？ラクスのR&Dで挑戦した垂直型の可能性 2025年、自律的にタスクを計画・実行する「AIエージェント」の登場は、ソフトウェア開発の世界に大きなインパクトを与えています。ラクス社では、この技術を自社サービスに取り入れ、進化させるために、R&D活動で「垂直型AIエージェント」の調査・研究に取り組みました。 AIエージェントは、ユーザーの指示に基づいて動く従来の生成AIやAIアシスタントとは異なり、与えられた目標に対して自ら計画を立て、状況に応じて判断し行動できるAIです。特に「垂直型AIエージェント」は、特定の業界や業務（ドメイン）に特化することで、高い専門性を発揮します...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250930

    株式会社ずんだもん技術室AI放送局 podcast 20250930
    Sep 29 2025
    youtube版(スライド付き) 関連リンク あえて二度手間することで取り戻す、AI時代のコーディングの楽しさ 最近、AIエージェントの進化により、開発スピードが驚くほど向上し、短時間でプロトタイプが作れるようになりました。しかし、この便利さの裏で、筆者は「コーディング本来の楽しさが半減している」というモヤモヤを感じています。 このモヤモヤの正体は、従来の開発にあった「学習」「理解」「試行錯誤」という重要なプロセスが、AI任せの開発ではごっそり抜け落ちてしまうことにありました。AIが代わりにコードを書いてくれるため、自分で調べたり、エラーと格闘したりする経験が減り、結果として以下の問題が生じます。 ノウハウが溜まらない: コードが動いても、なぜ動くのかの深い理解がないため、次に同じ問題に直面してもまたゼロから考えることになります。トラブルシューティングができない: 自分で試行錯誤していないため、バグが発生してもどこを直せばいいのか見当がつきにくくなります。メンテナンスが辛い: AIが生成したコードは、まるで他人が書いたかのように感じられ、改修や修正が困難になります。 そこで筆者が提案するのが「二度手間開発」です。これは、まずAIを使って最短で動くものを作り、次にそのAIが作ったコードを参考にせず、自分でゼロから同じものを作り直すという方法です。AIのコードは「チートシート」や「模範解答」のように活用し、わからない時だけ参照します。 実際に「二度手間開発」を試したところ、Chrome拡張機能の開発を通じて、WXTの設定の深い理解や、AIコード内の不要な部分の発見、さらにユーザー体験を向上させるアイデアなど、多くの具体的な学びと気づきがあったそうです。自分で手を動かすことで、コードがなぜ動くのか、どうすればもっと良くなるのかを深く考える機会が得られます。 「二度手間開発」を始めるコツは、AIのコードをあえて読まず、新しいプロジェクトで一から作り直すことです。そして、本当に困った時だけAIのコードを見てヒントを得ます。 AIは非常に強力なツールですが、効率化だけを追求すると、エンジニアとしての成長やコーディングの楽しさを失う可能性があります。あえて遠回りする「二度手間開発」を通して、AIを「学びのツール」として活用し、コーディング本来の喜びを取り戻すことができるでしょう。 引用元: https://www.m3tech.blog/entry/2025/09/29/110000 AIスパコン「さくらONE」のLLM学習ベンチマークによる性能評価 / SAKURAONE LLM Training Benchmarking さくらインターネットが開発したAIスパコン「さくらONE」を用いて、大規模言語モデル（LLM）の学習性能を評価した発表です。新人エンジニアの皆さんも、最先端のAI開発を支えるインフラ技術の現状と課題に触れてみましょう。 1. LLM学習におけるインフラの重要性 ChatGPTのような巨大なLLMの開発には、大量の計算を並行処理する高性能インフラが必須です。深層学習は、Webアプリとは異なり、大量のデータを一括処理する「バッチ型ワークロード」です。 学習を高速化する「分散学習」には、主に以下の手法があります。 データ並列: モデルを複製し、各GPUに異なるデータを処理させます。モデル並列: 巨大なモデルを分割し、複数のGPUで分担して処理します。 モデルの大規模化に伴い、GPUメモリ容量やGPU間のデータ通信速度がボトルネックになりやすいため、RDMAのような高速ネットワーク技術が学習効率を大きく左右します。 2. 国産AIスパコン「さくらONE」の特長 「さくらONE」は、さくらインターネットがLLM開発向けに構築したマネージドHPCクラスタです。 高性能GPU計算ノード、超高速ネットワーク、スケーラブルなストレージを統合。2025年のISC「TOP500」で世界49位の実績。特に、オープンなネットワーク技術（SONiC OS、800GbE Ethernet）を採用している点が特徴です。 3. LLM学習ベンチマーク評価と結果 さくらONEのLLM学習性能を客観的に評価するため、業界標準の「MLPerf Training」ベンチマークを実施しました。これは、GPT-3モデルの事前学習を対象に、目標精度達成までの実時間を計測するものです。 結果として、さくらONEは...
    Voir plus Voir moins
    Moins d'une minute
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250929

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250929
    Sep 28 2025
    関連リンク AI エージェント用の Chrome DevTools（MCP） Blog Chrome for Developers Chromeの開発チームは、AIエージェント向けの新しいツール「Model Context Protocol（MCP）サーバー」の公開プレビューを開始しました。これは、AIを活用した開発を大きく変える可能性を秘めています。 これまでAIコーディングアシスタントは、コードを生成できても、それが実際にブラウザでどう動くのかを直接確認するのが苦手でした。例えるなら、目隠しをしてプログラミングしているようなもので、問題の発見や修正が難しかったのです。 この課題を解決するため、Chrome DevTools MCPサーバーが登場しました。MCPとは、大規模言語モデル（LLM）のようなAIを外部のツールやデータに接続するためのオープンな標準プロトコルです。このサーバーは、AIエージェントにChrome DevToolsの強力なデバッグ機能やパフォーマンス分析機能を使えるようにします。これにより、AIがウェブページを直接チェックし、まるで人間のように問題を見つけて修正できるようになります。 AIエージェントがMCPサーバーを使うことで、以下のような様々なことが可能になります。 コード変更のリアルタイム検証: AIが生成したコードが、ブラウザで期待通りに動作するかを自動で確認できます。ネットワークやコンソールエラーの診断: ウェブページで画像が読み込まれない、フォームの送信に失敗するといった問題を、AIがネットワークリクエストやコンソールログを分析して原因を特定します。ユーザー行動のシミュレーション: AIが、フォーム入力やボタンクリックなどのユーザーの操作をシミュレートし、複雑なユーザーフローにおけるバグを発見します。スタイリングやレイアウト問題のデバッグ: AIがライブのウェブページを検査し、CSSの崩れやレイアウトの乱れといった視覚的な問題を特定し、具体的な修正案を提案します。パフォーマンス監査の自動化: ウェブサイトの読み込み速度が遅い場合、AIが自動でパフォーマンスを計測・分析し、改善のための具体的なアドバイスを提供します。 この新しいMCPサーバーは、簡単な設定を加えるだけで、すぐに試すことができます。AIエージェント開発者は、GitHubのドキュメントで詳細な使い方を確認できます。 この機能はまだプレビュー版で、開発チームはAIを活用した次世代の開発ツールをより良くしていくために、ユーザーからのフィードバックを積極的に募集しています。ウェブ開発におけるAIの可能性を広げる、非常にエキサイティングな一歩と言えるでしょう。 引用元: https://developer.chrome.com/blog/chrome-devtools-mcp?hl=ja Multi Agentを介した知識の活用の検討 - Preferred Networks Research & Development Preferred Networks（PFN）が、複数のAIを協力させて知識を最大限に活用する「Multi Agent（マルチエージェント）」という新しい手法の研究成果を発表しました。新人エンジニアの皆さんも、ぜひ知っておきたいAIの最新の活用事例です。 この研究では、AI同士が議論しながら最適な答えを見つける「LLM Debate（エルエルエムディベート）」というMulti Agentの手法を使いました。具体的には、PFNが独自に開発した医療分野に特化したAI「Preferred-MedLLM-Qwen-72B」と、高性能な汎用AIである「GPT-4o」を組み合わせ、医師国家試験の問題を解かせました。 AIを単体で使う場合、それぞれが持つ知識には得意なことと苦手なことがあります。そこで、両方のAIを協調させることで、お互いの得意な知識を補い合い、より正確な答えを導き出すことを目指しました。実験の結果、Preferred-MedLLM-Qwen-72BとGPT-4oを連携させた場合、単体で問題を解くよりも平均で約15点も正解率が向上し、医師国家試験で90%を超える高い正解率を達成しました。 この研究から、特に重要な点が2つ見つかりました。 専門知識を持つAIの重要性: ドメイン特化の学習をしていない一般的なAIとGPT-4oを組み合わせた場合は、正解率の向上がほとんど見られませんでした。この結果は、特定の分野の深い知識を持つAI（Preferred-MedLLM-Qwen-72Bのようなモデル）が、他のAIと協力して複雑な問題を解決する上で、非常に重要であることを示しています。専門知識...
    Voir plus Voir moins
    Moins d'une minute
  • 私立ずんだもん女学園放送部 podcast 20250926

    私立ずんだもん女学園放送部 podcast 20250926
    Sep 25 2025
    youtube版(スライド付き) 関連リンク Gemini Robotics 1.5 brings AI agents into the physical world Google DeepMindは、物理世界で機能するAIエージェントの新たな進化として「Gemini Robotics 1.5」と「Gemini Robotics-ER 1.5」を発表しました。この技術革新により、ロボットがこれまで以上に複雑で多段階のタスクを、まるで人間のように「考えて」実行できるようになります。 主要なモデルは二つです。 「Gemini Robotics 1.5」は、ロボットの目（視覚）と耳（言語指示）から得た情報をもとに、具体的な動き（アクション）を指示するモデルです。このモデルの特長は、行動する前に「どう動くべきか」を自分で考え、その思考プロセスを自然な言葉で説明できる点です。これにより、ロボットの行動がより透明になります。さらに、異なる種類のロボット（例えばアーム型や人型など）の間で学習した動きを転用できるため、新しいスキル習得が非常に効率的になりました。 もう一つは「Gemini Robotics-ER 1.5」です。これは、物理世界について深く推論し、Google検索のようなデジタルツールを自在に使いこなし、複雑なタスクのための詳細な計画を立てる、いわばロボットの「司令塔」のような役割を担います。このモデルは空間を正確に理解する能力に優れ、与えられたミッション達成のための多段階計画を自動で作成します。 これら二つのモデルは連携して動作します。まずGemini Robotics-ER 1.5が全体の戦略と高レベルな判断を下し、その計画に基づいてGemini Robotics 1.5が具体的な行動を指示・実行します。例えば、「洗濯物を色ごとに仕分けて」という指示に対して、ERモデルがインターネットで分別ルールを調べ、全体計画を立てます。その後、1.5モデルが実際に洗濯物を識別して適切な場所へ運ぶ、といった具体的な動きを担当します。これにより、ロボットは多様な環境やより長いタスクにも柔軟に対応できるようになります。 Google DeepMindは、これらのAIエージェント技術を安全かつ責任ある形で発展させることに重点を置いています。開発の初期段階から、ロボットが行動前に安全性を考慮したり、人間との適切な対話を行ったり、衝突回避システムと連携したりすることで、人間中心の環境で安心して利用できるロボットを目指しています。 このGemini Robotics 1.5は、物理世界における汎用人工知能（AGI）の実現に向けた重要な一歩と位置づけられています。単なる指示への反応を超え、自ら推論し、計画し、ツールを使いこなし、そして学習を汎化できるロボットの未来が期待されます。 開発者の皆さんへ：Gemini Robotics-ER 1.5は、Google AI StudioのGemini APIを通じて、本日より利用可能です。ぜひ、この新しい物理AIエージェントの可能性を探ってみてください。 引用元: https://deepmind.google/discover/blog/gemini-robotics-15-brings-ai-agents-into-the-physical-world/ Video models are zero-shot learners and reasoners Google DeepMindが発表した最新の研究は、動画モデル「Veo 3」がまるで人間のように、見たことのないタスクでも対応できる「ゼロショット学習」と「推論」能力を持つことを示しています。これは、AI分野、特に「マルチモーダルAI」（複数の情報形式を扱うAI）の進化において非常に重要な一歩です。 これまで、大規模言語モデル（LLM）がインターネット上の膨大なテキストデータを学習することで、人間が指示する様々な言語タスクをこなせる「基盤モデル」となりました。今回の研究は、同じように大規模な動画データを学習した生成動画モデルも、将来的にLLMが言語理解で果たした役割を、視覚理解の分野で果たす可能性を秘めていることを示唆しています。 Veo 3は、特定のタスク向けに明示的に訓練されていないにもかかわらず、驚くほど多岐にわたる視覚タスクをゼロショットで解決できます。例えば、動画から特定のオブジェクトを自動で切り抜いたり（セグメンテーション）、画像の端っこを認識したり（エッジ検出）といった基本的なことから、さらに以下のような複雑な操作が可能です。 画像・動画の編集: 背景の除去、スタイル変換、色付け、画像の足りない部分を補完するインペインティング、画像の外部を生成する...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250925

    株式会社ずんだもん技術室AI放送局 podcast 20250925
    Sep 24 2025
    youtube版(スライド付き) 関連リンク Why we built the Responses API OpenAIは、GPT-5のような最新の推論モデルや、今後のAIエージェント開発に最適な新しいAPI「Responses API」を発表しました。このAPIは、過去のAPI（Completions、Chat Completions、Assistants API）の経験から、開発者がモデルとより強力かつシンプルに連携できるように設計されています。特に、テキスト、画像、音声などを扱えるマルチモーダル（複数の情報形式を扱える）な推論モデルに最適化されています。 Responses APIの主な強み 推論状態の永続化: Responses APIの最大の特徴は、モデルの「推論状態」（モデルが考えたことの記録）を複数のやり取り（ターン）にわたって保持できることです。これは、まるで探偵が事件解決時に途中の調査メモを継続的に活用し、次のステップに進むようなイメージです。 これまでのChat Completionsではターンごとに推論がリセットされていましたが、Responses APIでは保持されるため、モデルはより効率的かつ高性能に動作します。これにより、ベンチマークで約5%の性能向上、キャッシュ利用効率も大幅に改善されます。 詳細な出力情報: モデルがユーザーに「何を言ったか」という最終的なメッセージだけでなく、「何をしたか」（例えば、どのツールを呼び出したか、途中のステップ）といった行動履歴も構造化されたリストとして出力されます。これにより、開発者はモデルの動作を詳細に把握でき、デバッグや監査、表現豊かなユーザーインターフェースの構築が容易になります。 強化されたホストツール: file_searchやcode_interpreterに加え、web search、image genなどの新しいツールがOpenAIのサーバー側で提供されます。ツール実行がサーバー内で完結するため、開発者は複雑なツール連携を自前で実装する手間が省け、通信の往復回数が減り、処理速度の向上とコスト削減に繋がります。 推論過程の安全な管理: モデルの思考過程（Chain-of-Thought）は、誤った情報（ハルシネーション）や不適切な内容が出力されるリスクを避けるため、直接クライアントには公開されず、OpenAIの内部で安全に保持されます。これにより、モデルの思考を監視・利用しつつ、安全で信頼性の高い応答をユーザーに提供できます。 OpenAIは、Responses APIが「ステートフル（状態を保持する）」、「マルチモーダル」、「効率的」であると強調しています。Chat Completionsも引き続き利用可能ですが、永続的な推論、ネイティブなマルチモーダル対応、シンプルなエージェントワークフローを求めるなら、Responses APIが最適です。OpenAIは、このAPIが今後のモデル開発のデフォルトになると考えています。 引用元: https://developers.openai.com/blog/responses-api/ StrandsAgents＋AgentCore Memory で私好みのエージェントを実現する この記事では、ユーザーの好みや過去の会話を記憶し、よりパーソナルな対応ができるAIエージェントの作り方について解説しています。特に、AIエージェント開発を支援する「Strands Agents」と、AWSが提供する「Bedrock AgentCore」の「Memory」機能を組み合わせて実現する方法が紹介されています。 Strands Agentsは、AIエージェントの振る舞いや会話の流れを柔軟に設計できるフレームワークです。これに、エージェントの実行環境や各種ツールとの連携、そしてユーザーごとの記憶管理機能を提供するBedrock AgentCoreを組み合わせます。Bedrock AgentCoreの目玉機能の一つが「AgentCore Memory」で、エージェントに短期記憶だけでなく、ユーザーの「Pythonが得意」「Angularが好き」といった好みを「長期記憶」として覚えさせることができます。この長期記憶は、過去の会話から得られた事実を記録し、現在の会話に関連する情報だけを動的に検索して活用するのが特徴です。 記事では、実際にMemory機能の有無でエージェントの応答がどう変わるかを検証しています。Memory機能がないエージェントは、一度会話を終えて新しいスレッドで同じような依頼をしても、ユーザーの以前の好みを忘れて、関係のない技術（例: Streamlit）を提案してしまいました。しかし、AgentCore Memoryを有効にしたエージェントは、新しい会話でも「PythonとAngularでの開発に興味がある」...
    Voir plus Voir moins
    Moins d'une minute
  • 株式会社ずんだもん技術室AI放送局 podcast 20250924

    株式会社ずんだもん技術室AI放送局 podcast 20250924
    Sep 23 2025
    関連リンク Introducing Notion 3.0 Notionが、その歴史上最大の進化となる「Notion 3.0」を発表しました。このアップデートの最大の目玉は、Notion AI Agents（AIエージェント）の導入です。これは単なるAIチャットボットの機能拡張ではなく、Notion内でのあなたの仕事を深く理解し、自律的にアクションを実行できる画期的なツールです。 これまでのNotion AIが特定のページでの簡単な質問応答や編集をサポートしていたのに対し、Notion AI Agentsは人間がNotionでできることの全てを代行できます。具体的には、ドキュメントの作成、データベースの構築、複数のツールを横断した情報検索、さらには複数のステップからなる複雑なワークフローの実行まで、まるでNotionのパワーユーザーが隣にいるかのように、あなたのタスクをこなします。 私たちの日常には「忙しいだけの雑務（Busywork）」が多く、本来集中すべき「人生を豊かにする本質的な仕事（Life’s work）」に時間を割けないことがあります。Notion AI Agentsは、この雑務を大幅に削減し、あなたがより創造的で価値のある仕事に集中できるようサポートします。例えば、「顧客からのフィードバックをSlack、Notion、メールから集約し、実用的なインサイトにまとめて構造化されたデータベースを作成する」といった複雑な指示にも対応し、完了したら通知してくれます。 さらに、このAIエージェントはパーソナライズ可能です。あなた自身の働き方や好みに合わせて、カスタム指示やコンテキストを与えることで、エージェントの振る舞いを細かく設定できます。まるであなた専用の有能なアシスタントのように、あなたのスタイルに合わせて作業を進めてくれるのです。エージェントに名前をつけたり、見た目をカスタマイズしたりする楽しさも提供されます。 そして、近い将来には「Custom Agents（カスタムエージェント）」が登場予定です。これは、特定の専門知識を持つAIエージェントをチーム全体で共有し、自動でタスクを実行させることができる機能です。例えば、日々のユーザーフィードバックの集計、週次プロジェクト更新の投稿、ITリクエストの自動トリアージなど、まるでAIスペシャリストのチームを雇うように、様々な業務を自動化できるようになります。 Notion 3.0は、Notionを単なるドキュメントやデータベース管理ツールから、AIが自律的に動く強力なワークフローハブへと進化させます。これにより、私たちの働き方が大きく変わり、より価値のある仕事に集中できる未来が期待されます。 引用元: https://www.notion.com/blog/introducing-notion-3-0 Smol2Operator: Post-Training GUI Agents for Computer Use Hugging Faceは、コンピューターのGUI（グラフィカルユーザーインターフェース）を自律的に操作できる軽量なAIエージェント「Smol2Operator」の開発について発表しました。このプロジェクトは、既存の画像とテキストを理解できるAIモデル（SmolVLM2-2.2B-Instruct）に、GUI操作スキルをゼロから学習させるための詳細なプロセスを解説しています。 GUIの自動操作はAI分野の大きな挑戦ですが、異なるGUI操作データセット間で操作の表現形式がバラバラである点が大きな課題でした。この問題を解決するため、本プロジェクトでは、モバイルやデスクトップなど様々な環境での操作指示を、統一されたコード形式に変換するデータ処理パイプラインを開発しました。特に、操作の座標を画面サイズに依存しない「正規化座標（0～1の範囲）」で扱うことで、異なる解像度の画像でも一貫して機能するように工夫されています。 学習プロセスは2つのフェーズに分かれています。 フェーズ1（知覚能力の獲得）では、まずAIがGUIのスクリーンショットからボタンやテキストボックスといった要素を正確に「見て、認識し、その場所を特定する」能力を学習させました。最初は全くGUIを認識できなかったモデルが、この段階で大幅な性能向上（特定のベンチマークで41%改善）を見せました。 フェーズ2（推論能力の獲得）では、知覚能力を土台に、AIが「タスクの指示を理解し、その達成のために自律的に考え、複数の操作手順を計画して実行する」能力を学習させました。...
    Voir plus Voir moins
    Moins d'une minute
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250922

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20250922
    Sep 21 2025
    関連リンク Server Less Code Moreキーノートレポート【ServerlessDays 2025】 この記事は、ServerlessDays 2025のキーノート「Server Less Code More」のレポートで、AIエージェントをサーバーレス環境で開発する際の重要な考え方を、新人エンジニアにも分かりやすく解説しています。 まず、大規模言語モデル（LLM）が大きく進化した転換点として、Claude 3.5 Sonnetと「ToolUse」の登場が挙げられます。ToolUseのおかげで、AIがファイルを読み書きするなど外部のツールと連携できるようになり、これによりAIが自律的にコードを書く「コーディングエージェント」の原型が生まれました。この進化が、AIエージェント開発の可能性を大きく広げたのです。 次に、サーバーレスとAIの組み合わせについてです。Amazon BedrockのようなAIサービスと、スマートフォンのアプリのようなネイティブアプリケーションを直接組み合わせることで、「これこそサーバーレス」と言えるような非常にシンプルな構成が実現できると示されました。従来の、API GatewayとLambdaを必ず使うという固定概念にとらわれず、よりシンプルにサービスを構築できる選択肢があることを示唆しています。 また、サーバーレス開発における普遍的なデザイン原則として、以下の3つが特に重要だと強調されています。 関数単位での設計: アプリケーションの各機能を独立した「関数」として設計し、どんな環境でも動かせるようにしておくこと。ステートレス: 処理が実行されるコンピューター自体にデータ（状態）を保存せず、データはデータベースなどの外部に保存すること。これにより、処理をスケールしやすくなります。イベントドリブン: 何か特定の「イベント」（例えば、ファイルがアップロードされた、ユーザーがボタンを押したなど）をきっかけに処理が自動的に始まるようにすること。 これらの原則は、AIエージェントの開発においても非常に重要だと述べられています。 LLM単体には、「最新の情報に詳しくない（ナレッジカットオフ）」「外部のシステムを直接操作できない」「以前の会話内容を覚えていない（ステートレス）」といった制約があります。これらの弱点を克服するためには、アプリケーション側で「コンテキストの注入」が必要です。具体的には、AIに目的や役割を指示する「システムプロンプト」、過去の会話履歴を管理して渡す仕組み、そして外部のデータベースやドキュメントを参照してAIの知識を補う「RAG（Retrieval Augmented Generation）」といった技術が活用されます。 しかし、これらの工夫だけではAIの自律的な行動には限界があり、そこで「AIエージェント」が必要になります。 キーノートの重要なメッセージの一つは、「AIエージェントはアプリケーションである」ということです。これは、AIエージェントが全く新しい特別なものではなく、これまでのソフトウェア開発の延長線上にあるものとして捉えるべきだという意味です。AIエージェントは、LLMが「次に何をすべきか思考」し、その思考に基づいて適切な「ツールを実行」し、その実行結果を受けて再び「思考」するというループを繰り返して動作します。 大規模なAIエージェントを開発する際には、シンプルなエージェントでは気にしなかったような、認証・認可（誰が何を使えるか）、メモリ管理（会話履歴などの情報の効率的な管理）、監視（オブザーバビリティ）、エラーハンドリングといった、従来のアプリケーション開発で複雑になる要素も考慮する必要があります。 これらの大規模エージェント開発の課題に対し、AWS上でのStrands Agents SDKを活用した解決策も提示されています。例えば、ステートレスなLambda環境で会話履歴を継続的に保持するためには、DynamoDBなどの外部ストレージに状態を保存することが必須です。また、エージェントの主要なロジックや、LLMが使う各ツールは、再利用しやすいように独立した関数として設計することが推奨されます。最終的なAIエージェントのアーキテクチャは、従来のサーバーレス構成にBedrockなどのLLMサービスが加わる形となり、ここでもサーバーレスの3原則である「関数単位」「ステートレス」「...
    Voir plus Voir moins
    Moins d'une minute