Avsnitt
-
今回は、Anthropicが満を持して一般公開したMythos級モデルClaude Fable 5を、リリース当日からお互いに実戦投入してみた初感を持ち寄りました。
僕はCodex CLI（GPT-5.5）では辿り着けなかった複雑なバグを含む、4つのバグ調査を一気に投げ、阿部さんは寝る直前にダメ元でシステム全体のリアーキテクトを依頼。翌朝それぞれが目にした結果とは。さらに「実行が速い」と感じる阿部さんに対して、僕の体感は意外にも「遅い」。それなのにトータルでは速いと感じてしまう、この逆説の正体がひとつの論点になっています。
SWE-bench ProやGDPval-AAのスコアの伸び方も含め、これまで大局観と細部の精度を別モデルに分担させてきた僕らの開発スタイルそのものを問い直される回でした。レビューサイクルやトークン消費の話まで、前提が一段更新された感覚があります。
終盤では、ここ数日で急に話題になっている「ループエンジニアリング」にも触れていますが、二人とも思うところがありすぎたため、また別の時に詳しくお話ししたいと思います。
▼Claude Fable 5（Anthropic公式発表）
https://www.anthropic.com/news/claude-fable-5-mythos-5
▼Claude
https://claude.ai/
▼Claude Coworkが1週間分無料でトライアルできる招待コード
https://claude.ai/referral/PMQIAlW1uQ?s=cowork&v=apps
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、僕がずっと心待ちにしていたMiniMax M3がついに登場したので、無料でも試せるOpenCodeにそのまま載せて、手元のバグ調査で使い倒した感触をお話ししています。
比較対象はClaude Code経由のClaude Opus 4.8、そしてOpenCode経由のGPT-5.5とDeepSeek V4 Pro。同じお題を横並びで追わせました。僕がMiniMaxに惚れ込んでいた理由は、速さと安さ、コーディング以外にも使えるトークンプランの自由さ、100万トークンでも失速しないという触れ込みに加え、動画のネイティブ理解です。期待値だけなら誰よりも高かったはず。対する阿部さんはDeepSeek V4 Proにすっかり満足していて、まずは僕のレビュー次第、という温度差からの幕開けでした。
結論そのものは番組に譲りますが、ベンチマークの数字と実際の手触りはどうしてもズレる、という地点へ何度も引き戻されます。白黒つけたというより、次に確かめたい宿題がくっきり残った回になりました。
ちなみに今回から試験的に映像も回しているのは、編集をAIに委ねたいから。だからこそM3が前面に掲げる動画理解はまだ試しきれておらず、ここは改めて続報としてお届けします。
▼MiniMax M3
https://www.minimax.io/blog/minimax-m3
▼DeepSeek V4 Pro
https://www.deepseek.com/
▼OpenCode
https://opencode.ai/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
Saknas det avsnitt?
-
今回は、僕がエンジニアの手を借りずにポッドキャストの編集自動化を作り切った体験を起点に、AI駆動開発で生産性を最大化する進め方について語っております。
驚いたのは、AIが僕の想像の外から技術を見つけてきて実装してしまったこと。「頭の良さより、考えを更新し続ける姿勢が3倍効く」というスーパー予測者の研究とも重なり、AIとの向き合い方を更新させられました。
僕は「設計を詰めるより、まず実装させて一晩でイテレーションを回す方が速い」と考えているのですが、エンジニアの阿部さんは「それには適用範囲がある」と。インフラや外部連携、責務境界が絡むと、そう単純ではないようで。この違いはどこから来るのか？
「次に詰まるのは人間なのでは」という観点も含め、最後まで意見は平行線。それでも、議論しがいのある回になったと思います。
後半は、DeepSeek-V4 Proが主力になりつつある驚きや、Claude Code・Codex・opencodeの使い分けについても話しています。
▼Claude Code
https://claude.com/product/claude-code
▼Codex
https://openai.com/codex/
▼opencode
https://opencode.ai/
▼Claude Design
https://www.anthropic.com/news/claude-design-anthropic-labs
▼DeepSeek
https://www.deepseek.com/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、AI駆動開発で日々の作業場となったターミナルに何を求めるか、そして阿部さんが見つけてきたMuxyというターミナルを起点に語っております。
僕はこれまでiTerm2からkitty、Ghostty、そしてWarpへと渡り歩いてきました。Warpをかなり気に入っていた僕に対して、阿部さんはあっさり不採用の判断。この違いはどこから来るのか？
純正のターミナルにこだわる阿部さんと、リッチな機能に惹かれる僕。ターミナルへの向き合い方の違いが全然違うなと感じました。
後半は、阿部さんがターミナルに求める条件を深掘り。ZedやCursor、Googleが出したAntigravityにも触れながら、なぜ多くの開発環境が「あと一歩」なのかを話しています。Muxyが本当に運用に乗るのか、引き続き検証していきます。
▼Muxy
https://muxy.app/
▼Warp
https://www.warp.dev/
▼Ghostty
https://ghostty.org/
▼kitty
https://sw.kovidgoyal.net/kitty/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、Claude Designを阿部さんが実際に触ってみての感想と、デザイン作業から実装までのワークフローをどう組み立てるかについて語っております。
僕がここ数回プッシュし続けてきたClaude Designに対して、エンジニア視点の阿部さんが触ったらどう感じるのか？「革命的」と評する一方で、自社システムのデザインを土台にAIへ的確に指示を出すには一工夫必要だったようで、そこをどう乗り越えたのか興味深いポイントでした。
特に阿部さんが見つけた、あるChrome拡張機能を使った合わせ技には、僕も「これは応用できそうだ」と気づきの多い時間となりました。
後半では、実体を先に作ってからデザインを改善する開発フローの考え方や、Moonshot AIが出したKimi Web Bridgeと組み合わせたときに広がる可能性についても触れています。
Claude Design 関連リンク
https://claude.ai/design
SingleFile 関連リンク
https://chromewebstore.google.com/detail/singlefile/mpiodijhokgodhhofbcjdecpffjipkle
Kimi Web Bridge 関連リンク
https://www.kimi.com/features/webbridge
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「中華モデルにオーケストレーター役（親エージェント）を任せる日は本当に来るのか？」というテーマで、DeepSeekが公開したDeepSeek-V4-ProとDeepSeek-V4-Flashについて語っております。
これまでGLM-5.1やKimi K2.6、MiniMax M2.7を試してきた僕ですが、長時間駆動や複雑なワークフローではどこかで限界を感じていました。100万トークンコンテキストとハイブリッドアテンション設計を備えた今回のモデル、巷で噂される「研究者気質で硬い」評価はどう転ぶのか？阿部さんとの実機検証は、世間の評判とはまた違った景色が見える時間となりました。
加えて、月10ドルから始められるサブスクリプションOpenCode Go経由での運用構成にも触れています。コスト感も含めて開発スタイルがどう変わりうるのか、気になる方はぜひ聞いてみてください。
▼DeepSeek-V4 Preview リリースノート
https://api-docs.deepseek.com/news/news260424
▼DeepSeek-V4-Pro(openrouter)
https://openrouter.ai/deepseek/deepseek-v4-pro
▼DeepSeek-V4-Flash(openrouter)
https://openrouter.ai/deepseek/deepseek-v4-flash
▼OpenCode Go
https://opencode.ai/go
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「Claude Designを実際の開発で使ってみた」という体験を起点に、AI駆動開発のワークフローについて語っております。
実装後のスクショを渡してClaude Designで洗練させていく僕に対して、以前Pencilでデザインを先に固めようとしていた阿部さん。「先に実装か、先にデザインか」という根本的な順序の話で、かなり意見が分かれるポイントでした。
お互いの試行錯誤を共有しながら、Claude Codeとの連携も含めて現時点でワークしそうなフローを探っていく、気づきの多い時間となりました。
後半は、Subquadraticが出した1200万トークンの新モデルSubQや、エージェント時代を見据えた分散データベースTursoにも話が広がっております。これらが実用レベルなら、開発の前提そのものが変わるかもしれません。
Claude Design 関連リンク
https://www.anthropic.com/news/claude-design-anthropic-labs
Pencil 関連リンク
https://pencil.dev/
SubQ (Subquadratic) 関連リンク
https://subq.ai/
Turso 関連リンク
https://turso.tech/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、OpenAIが公開したGPT-5.5の公式プロンプトガイドを起点に、新モデルの使用感とプロンプト設計の本質について語っております。
「アウトカムだけ伝えれば短いプロンプトで動く」というガイドの主張に対して、僕は『結局、踏ませたいステップは書くしかなくないか？』という違和感を抱いていて、プロンプトガイドを読み込んできてくれた阿部さんも近い感触を持っているようでした。一方で、5.5になってから増えた"勝手に作業を始めてしまう"振る舞いには、お互いかなり手を焼いている様子。
そこから話は、AIに余白を残しながら高品質を引き出す"マジックワード"論や、コンテキストをクリーンに保つコツ、Cognition AIが論じる文脈管理の話まで広がり、お互い気づきの多い時間となりました。モデル更新のたびにプロンプトをどう見直すべきか、その判断軸についても踏み込んでいます。
▼GPT-5.5 プロンプトガイド
https://developers.openai.com/api/docs/guides/prompt-guidance?model=gpt-5.5
▼Cognition AI「Don't Build Multi-Agents」
https://cognition.ai/blog/dont-build-multi-agents
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、最近触ってみて想像を大きく超える体験だったClaude Designについて語っております。スライド生成やデザイン作成ツール、というのが事前の印象だったのですが、実際に使ってみるとその枠を超えた驚きがありました。
僕はYouTube動画用のアイコンやフレーム、サムネイル生成のために使い始めたのですが、気づけばAIが「デザイン管理システム」のようなものを勝手に組み上げ始めていて。一貫性のあるアセットを再現性高く量産できる仕組みが、対話の中から自然に立ち上がってくる感覚は、これまでのデザインツールとは何かが根本的に違うように感じました。
後半では、Shopifyやfreeeが進めるMCP公開戦略と、マネーフォワードが出すCoworkとの方向性の違いについても触れています。サービス内にAIを搭載するのか、外部のAIから操作できる環境を提供するのか。これからのサービス設計の前提条件が変わりつつあるのを感じる回となりました。
Claude Design 関連リンク
https://claude.ai/design
Claude Design 公式発表ブログ
https://www.anthropic.com/news/claude-design-anthropic-labs
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、リリース直後のGPT-5.5を実際にサブスクリプションプランで触ってみての所感について語っております。
長文コンテキスト耐性やコーディング性能のベンチマークが軒並み向上したと発表されている一方で、僕も阿部さんも、数字以上に「体感が変わった」と感じている部分があり、その正体はどこから来るのか？というところがひとつのテーマになりました。
GPT-5.4との比較で、応答速度・回答のシンプルさ・ツール選択の判断・粘る力のどこがどう効いているのか、お互いに使ってみての気づきを持ち寄る回となっています。
後半では、Fastモードのレート消費が1.5倍速で2.5倍消費に変わった話や、サブスクの枠の減り方が直近で挙動を変えてきている件についても少し触れております。
GPT-5.5 関連リンク
https://openai.com/index/introducing-gpt-5-5/
Codex 関連リンク
https://openai.com/codex/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、リスナーさんから頂いた3件のお便りに答える形で、『MiMo-V2-Proを使ってみた所感』『AIの記憶をどう管理するかについて』『生成AIの情報収集をどう行っているか』について語っております。
1件目はXiaomiが出したMiMo-V2-Proについて。OpenRouterで一時1位になっていた、100万トークンコンテキスト対応のモデル「MiMo-V2-Pro」を使ったことのある阿部さんの評価はどうだったのか、Qwen3.6 PlusやGLM-4.6、GLM-5.1、MiniMax-M2.1との比較も踏まえて話しています。僕が最近使ったQwen CodeでのQwen3.6 Plusの使い勝手についても触れています。
2件目の情報収集では、XやReddit、ChatGPTのDeep Research、MastraやCloudflare、OpenAI、Anthropic、Stripe、Shopify、Vercelの技術ブログの使い分けなどを共有。さらにOpenRouterのモデルランキング、YouTube、OpenCodeやOh My OpenCode、OpenHands、Gemini CLIのチェンジログ確認など、普段の情報源をかなり具体的に話しました。同じAI駆動開発をしているはずなのに、僕と阿部さんで見に行く先がくっきり分かれたのが印象的で、お互い気づきの多い時間となりました。
後半は、『過去の会話履歴をスキルでステアリングできないか』というお便りから、OpenCodeがSQLiteにセッション履歴を蓄積する仕組みの活用、そしてSupermemory（opencode-supermemoryプラグイン）やCipher（ByteRover）といった記憶レイヤー系ツールに話が広がりました。Claude CodeやCodexとの違い、Serenaとの位置付けの違いにも触れつつ、立ち上げ期と運用期で必要な記憶の質は違うのではないか、という手応えもあります。
▼MiMo-V2-Pro 関連リンク
https://openrouter.ai/xiaomi/mimo-v2-pro
▼Qwen3.6 Plus 関連リンク
https://openrouter.ai/qwen/qwen3.6-plus
▼QwenCode 関連リンク
https://qwen.ai/qwencode
▼OpenCode 関連リンク
https://opencode.ai/
Supermemory 関連リンク
https://supermemory.ai/
▼opencode-supermemory 関連リンク
https://github.com/supermemoryai/opencode-supermemory
▼Cipher（ByteRover） 関連リンク
https://github.com/campfirein/byterover-cli
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、Z.aiのGLM-5.1とAlibaba Qwen TeamのQwen 3.6 Plus Previewを実際にエージェント開発で使ってみた感想について語っております。
僕も阿部さんも期待していたGLM-5.1ですが、実際にOpenCode上でサブエージェントとして動かしてみると、思わぬ不安定さに直面しました。一方で、100万トークンのコンテキストウィンドウを持つQwen 3.6 Plus Previewは、ロングコンテキストでの安定性やトークン出力の速さなど、想像以上の良い感触がありました。この違いはどこから来るのか？20万トークンと100万トークンの差以外にも色々な観点で話し合い、かなり意見が割れるポイントもありつつ、お互い気づきの多い時間となりました。後半では、Holo3やKAT-Coder-Pro V2、Arcee AIのTrinity-Large-Thinkingなど、気になる新モデルの話題にも触れています。
▼GLM-5.1 コーディングプラン
https://z.ai/subscribe
▼Qwen 3.6 Plus Preview（OpenRouter）
https://openrouter.ai/qwen/qwen3.6-plus-preview:free
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「AI駆動開発において、なぜエンジニアほどAIに任せきれないのか？」という僕自身の気づきを起点に、AI駆動開発の考え方そのものについて語っております。
先日、北海道の鶴居村で羊飼いの方を訪問した経験から、エンジニアの仕事は「料理人」、AI駆動開発は「農家」に近いのではないかという話をしています。料理人は自分の技術で直接品質を作り上げる。一方、農家や羊飼いは生き物に直接手を加えられないからこそ、環境整備に全力を注ぐ。この違いがAIとの向き合い方にも通じるのではないか。
僕から「Environment Engineering」という言葉を出してみたところ、阿部さんもコンテキストエンジニアリングやハーネスエンジニアリングを包括するより大きな枠組みとしてしっくり来ると言う話に。ただ、エンジニアは自分でも介入できるがゆえに、つい手を出してしまうというジレンマも。AIを単なる効率化ツールではなく、自分には出せない品質を引き出す存在としてどう"環境"を整えるか、お互いまだ整理しきれない部分も含めて率直に話しました。
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「MiniMax M2.7をAIワークフローに組み込んだらどうなるか」という僕の試行錯誤について語っております。
MiniMaxが新しく始めたToken Planでは、コーディング以外の用途にもサブスクで使えるようになり、GLM-5の約1/3のコストで回せる可能性が出てきました。そこで、Mastraで組んでいる記事生成ワークフローのモデルをGLM-5からMiniMax M2.7に差し替えてみたのですが、そこで見えてきた課題が想像以上に根深くて。中国語の文字が混じる問題、文脈が破壊される問題、Structured Outputに対応していない問題と、なかなか一筋縄ではいかない結果に。この辺り、OpenCodeがモデルごとにプロンプトを変えている理由にも通じる話で、お互い気づきの多い時間となりました。
結局のところ、今のところはGLM-5が安定しているという結論に落ち着いたわけですが、中華モデルの得意・不得意の輪郭がより見えてきた回でもあります。
▼MiniMax M2.7
https://www.minimax.io/models/text/m27
▼MiniMax Token Plan
https://platform.minimax.io/docs/token-plan/intro
▼Mastra
https://mastra.ai/
▼OpenCode
https://opencode.ai/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、Kimi K2.5を実際にエージェント駆動開発の現場で使ったらどうなるのか、という検証結果について語っております。
Moonshot AIが発表したKimi K2.5は、Agent Swarmやマルチモーダル対応など魅力的な特性を持ち、僕もかなり期待していたモデルです。実際にKimiのアプリでLP制作を試した際の出来栄えが良かったこともあり、阿部さんにOpenCode上のオーケストレーターとして実戦投入してもらいました。ところが、GLM-5と比較したときに見えてきた差が、なかなか興味深い結果でした。
単発のタスクと複合的な分析タスクで評価が大きく分かれるポイントがあり、「ベースモデルとしての優秀さ」と「素で使う実力」の違いについて、Composer 2の話題も交えながらお互い気づきの多い時間となりました。
▼Kimi K2.5
https://www.kimi.com/ai-models/kimi-k2-5
▼OpenCode
https://opencode.ai/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「GPT-5.4のコストに見合うメリットが感じられない」という話を起点に、何を基準にモデルを選ぶべきなのかについて語っております。
100万トークン対応や自律的な長時間実行といったGPT-5.4の強みは、OpenCodeとOhMyOpenCodeの組み合わせでカバーできてしまう。それならGPT-5.3-Codexの方がコードベースの理解力もコスパも優れているのでは、というのが僕の仮説で、阿部さんも近い感覚を持っていたようで、かなり意見が一致するポイントでした。
さらに、OhMyOpenCodeのリポジトリにあるエージェントごとのデフォルトモデルやフォールバックチェーンの設計を読み解いていくと、なぜこのエージェントにこのモデルなのかという配置の意図が見えてきました。
OpenCodeの知見など、新たにわかったことについてもシェアしているのでぜひ聞いてみてください。
▼GPT-5.3-CodexとGPT-5.4の価格比較 - OpenRouter
https://openrouter.ai/compare/openai/gpt-5.4/openai/gpt-5.3-codex
▼OhMyOpenCodeのモデル選択ガイドライン - GitHub
https://github.com/code-yeongyu/oh-my-openagent/blob/dev/docs/guide/agent-model-matching.md
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、3月5日にOpenAIがリリースしたGPT-5.4を実際に使ってみて、前モデルのGPT-5.3-Codexとどう違うのか、どう使い分けるべきかについて語っております。
阿部さんはCodex CLIで、僕はOpenCodeでそれぞれ使い込んだのですが、「コーディング精度は5.3-Codexの方が上では？」という阿部さんの実感と、「オーケストレーター的な役割には5.4が合う」という僕の感覚には、実は根本的な考え方の違いがありました。言うなれば5.3-Codexは「内性的な職人気質のエンジニア」、5.4は「頭の切れるビジネスマン」のようなもので、この性格の違いをどう活かすかが、かなり意見の分かれるポイントでした。
さらに後半では、GPT-5.4が最大100万トークンのコンテキストウィンドウをサポートしたことに触れつつ、API料金が272Kトークンを超えると跳ね上がる仕組みを発見。コンパクションの設定をどうすべきか、お互い気づきの多い時間となりました。
▼GPT-5.4発表 - OpenAI
https://openai.com/index/introducing-gpt-5-4/
▼1M tokenの性能比較 - Claude
https://claude.com/blog/1m-context-ga
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「Codexのウィークリーリミットが3日で尽きてしまう」という僕たちの切実な悩みを起点に、その解決策として注目しているOpenCode＋Oh My OpenCodeについて語っております。
以前試した時は安定感に欠けていたOpenCodeですが、今回改めて使うとかなり成熟していて、さらにオーケストレーションレイヤーのOh My OpenCodeを組み合わせることで、阿部さんは1時間が限界だったコーディングセッションが5時間のロングランに化けたと言います。SisyphusやOracle、Prometheusといったエージェントの使い分けや、Ultraworkの仕組みなど、僕と阿部さんでかなり運用の方向性が違っていて、お互い気づきの多い時間となりました。
後半では、Mastra Codeが採用しているObservational Memoryという記憶の仕組みにも話が及び、コンパクションに頼らない中期・長期記憶の考え方が、今後のAIサービス開発にどう活きるのかという話題でも盛り上がりました。
OpenCode 公式サイト
https://opencode.ai/
Oh My OpenCode
https://ohmyopencode.com/
Mastra Code 公式サイト
https://code.mastra.ai/
Mastra Observational Memory ドキュメント
https://mastra.ai/docs/memory/observational-memory
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、「AIレビューが爆量に返ってきて人間がボトルネックになる問題」を起点に、AI駆動開発におけるレビュー体制と自動化について語っています。
僕たちのチームでは Codex、CodeRabbit、Claude、Devin の4つのAIレビュアーを導入しています。これらについてどのレビュアーの指摘が的確で、どれが参考程度でよいのかなど、各ツールの評価について2人の意見を話し合いました。
AIのレビューと修正を繰り返すうちに、1つのPRがコメント375件・約80コミットまで膨れ上がってしまい、人間が手動で付き合い続けるのは現実的ではないという課題も浮き彫りに。
後半では、阿部さんがこの課題を解決するためにGitHub CLIの仕組みに基づき、CLIの拡張機能を自作・公開した話や、sleepコマンドを使ってAIによるレビュー対応と再確認の自動イテレーションを回す仕組みなど、具体的な改善策に踏み込んでいます。
レビューの妥当性検証をどこまで自動化できるのか、お互い気づきの多い時間となりました。
▼CodeRabbit
https://www.coderabbit.ai/
▼Devin
https://devin.ai/
▼Github CLI
https://cli.github.com/
▼ 阿部さんが自作したGithub CLIの拡張機能
https://github.com/abekdwight/gh-pr-review-check
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f -
今回は、以前も話題にした音声入力アプリAmicalのアップデートとして、阿部さんがVoiceOSやApple純正の音声入力を経て再びAmicalに戻ってきた経緯について語っております。
スクリーンショットのコンテキストを読み取って文章を生成してくれるVoiceOSの機能に惹かれつつも、実際に使ってみると出力の精度に課題があったという阿部さん。一方でApple純正はレスポンスの速さと安定感が魅力だけれど、カタカナや英語の変換に弱い。この三つ巴の中でなぜAmicalに軍配が上がったのか、それぞれの強みと弱みが浮き彫りになるやり取りでした。
後半では、Amicalの言語設定を英語にすると日本語の発話がそのまま英語に翻訳されるという偶然の発見から、コンテキスト効率やAIへの入力最適化の話へ展開。さらに音声入力が前提になった世界では、キーボードの配置やパソコンの形状そのものが変わるのではないかという未来の話にまで広がりました。
▼Amical 公式サイト
https://amical.ai/
▼VoiceOS 公式サイト
https://www.voiceos.com/
---
stand.fmでは、この放送にいいね・コメント・レター送信ができます。
https://stand.fm/channels/68dc82a9036795923c400b4f - Visa fler
