AI/LLM

AWS が 2026 年 4 月 28 日に開催したイベント「What’s Next with AWS 2026」で、Amazon Quick のデスクトップアプリ（Preview）が発表・リリースされた。エンタープライズ向けのセキュアな AI アシスタントとして、Claude Code を含む開発者ツールとの MCP 連携も備えている。 Amazon Quick とは Amazon Quick は AWS が提供するデスクトップ AI アシスタントで、ユーザーの日常業務を横断的に支援することを目的に設計されている。今回のデスクトップアプリリリース以前から Web・モバイル版が存在していたが、OS レベルの統合が加わったことで機能が大幅に拡張された。 対応 OS は macOS と Windows の両方。AWS アカウントは不要で、個人メール・Google・Apple・GitHub・Amazon 認証のいずれかでサインアップできる。 主な機能 パーソナル知識グラフによるコンテキスト学習 Amazon Quick はバックグラウンドで動作するデスクトップ常駐アプリで、ユーザーが明示的に接続した SaaS 統合（Slack・メール等）と、許可したローカルフォルダからエンティティ（人物・組織・プロジェクト・イベント・ドキュメント等）を抽出して「パーソナル知識グラフ」を構築する。会話のたびにゼロから始めるのではなく、蓄積したグラフを参照して返答するのが特徴だ。 データ取得経路は次の 3 つに限定されており、画面録画・キー入力フック・アクセシビリティ API といった OS レベルの「横取り」は行わない: Auto-ingest from integrations — 接続済み SaaS の正規 API 経由でメッセージ・送受信者などを取り込む。Slack / Email / その他のソースタイプごとに個別トグルで ON/OFF ローカルフォルダ（オプトイン） — Settings > My computer でフォルダ単位に「Knowledge graph extraction」を明示的に有効化したフォルダだけをローカルでインデックス化（クラウドにアップロードはしない） チャット内での手動追加 — 会話中にユーザーが指示してエンティティを追加 抽出した知識グラフは ~/.quickwork/ にローカル保存され、クロスデバイス継続のため AWS アカウントへバックアップされる。AI モデルの学習には一切使用されない。 ...

千寻（@Crypto_QianXun）さんが2026年4月のポストで紹介した「Claude + YouTube Shorts = 自動収益化」という手法が注目を集めている。カメラなし・編集なし・顔出しなし でバイラルショート動画を量産するアプローチだ。 この記事では、そのコンセプトをもとに、Claude を使った YouTube Shorts コンテンツ自動生成のフローと実践的なプロンプト例・Python コードを解説する。 YouTube Shorts アルゴリズムが評価する要素 — 顔出しなしでも収益化できる理由 YouTube Shorts のアルゴリズムは 視聴継続率・エンゲージメント をコンテンツ品質の代理指標として評価する。次の3点が鍵になる。 フック（冒頭3秒） で視聴者を引き込めるか 情報密度 が高く最後まで見られるか 感情を動かす テキスト・ナレーションがあるか これらは人間が画面に映らなくても Claude が生成したスクリプトで十分に実現できる。AI 音声と AI 生成画像/映像を組み合わせれば、顔出し不要のチャンネルが成立する。 Claude を使ったコンテンツ生成フロー Claude が担うのは最初のスクリプト生成だが、これがコンテンツ全体の品質を左右する最重要ステップだ。 Claude でバイラル Shorts スクリプトを生成するプロンプトの型 1. フック特化型プロンプト 1 2 3 4 5 6 7 8 9 10 11 あなたは YouTube Shorts のバイラル専門家です。 トピック：[テーマ] 以下の構成で60秒のスクリプトを書いてください： - 冒頭3秒：視聴者が思わず止まる衝撃的な問いかけ or 事実 - 本編45秒：テンポよく箇条書きで展開 - ラスト12秒：CTA（コメント誘導 or 保存促進） 制約： - 一文は短く（15文字以内） - 数字を多用する（例：「94%の人が知らない」） - 感情語を入れる（驚き・不安・希望） 2. ジャンル×バイラル要素の組み合わせ型 バイラルになりやすいジャンルとその鉄板フレーズを Claude にコンテキストとして渡してスクリプトを生成させる： ...

AI を使っていて「最近 ChatGPT や Claude が急に使いにくくなった」と感じたことはないだろうか。中国の AI コミュニティで話題になった阿绒 AYi（@AYi_AInotes）が、この感覚の正体を鮮やかに考察している。本記事はその考察をもとに筆者が整理したものだ。 公式ガイドラインが相次いで公開された 2026年4月、Anthropic が Claude Opus 4.7（4月16日）、OpenAI が GPT-5.5（4月23日）のリリースに合わせ、それぞれ公式のプロンプトエンジニアリングガイドラインを公開した。モデルが「バカになった」わけではない。むしろ賢くなりすぎた結果、曖昧な指示への耐性がなくなったのだ。 面白いのは、2つのモデルの進化の方向性が完全に真逆だという点だ。 Claude は「字義通り」に、GPT は「自律的」に Claude Opus 4.7 の変化 Claude は以前、曖昧な指示を受けると自分でいい感じに補完してくれていた。「なんとなくこんな感じで」という指示でも、文脈を読んで意図を推測し、それなりの出力を返してくれた。 今の Claude は違う。あなたが言ったことをそのまま実行する。推測も補完もしない。「一文字も余計に解釈しない」スタイルに変わっている。 GPT-5.5 の変化 GPT はかつて、ステップバイステップで丁寧に教えないとうまく動かなかった。「まず A をして、次に B をして、最後に C を確認して」という細かい手順指示が必要だった。 今の GPT は自律的だ。「こういう結果が欲しい」と伝えるだけで、最適なアプローチを自分で選ぶ。手取り足取り教える必要がなくなった。 古いプロンプトが失敗する理由も真逆 この進化の方向性が真逆なので、古いプロンプトが失敗する理由も正反対になる。 モデル 失敗するプロンプト 失敗の理由 Claude 曖昧・ふんわりした指示 字義通りに解釈するため、意図とかけ離れた出力になる GPT 細かすぎる手順指示 自律的に判断するため、冗長な手順が逆にノイズになる Claude に「いい感じで頼む」と言えば言うほど出力がおかしくなる。GPT に「まず○○して、次に□□して」と細かく指示するほどかえってうまくいかない。 プロンプトエンジニアリングの本質が変わった ChatGPT が広く普及した2023年以来の約3年間、私たちは「モデルにどう教えるか」を学んできた。どう指示すれば動くか、どう補足すれば正確になるか。 いまや立場が逆転している。モデルが私たちに「先に自分の考えを構造化してくれ」と求めている。 これはプロンプトエンジニアリングの本質そのものだ。「モデルにどうやって動かすかを教える技術」から、**「自分が何を本当に求めているかを先に明確にする技術」**へと変わった。 本当のボトルネックは、モデルの能力ではなく、プロンプトを書く人の「思考の明確さ」かもしれない。 勝者は「最も明確に考えられる人」 最も長く複雑なプロンプトを書ける人が勝つ時代は終わった。 これから重要なのは、自分が本当に何を求めているのかを最も明確に理解している人だ。 モデルへの指示を洗練させることに時間をかけるより、自分の思考を整理する時間をかける価値が出てきている。プロンプトエンジニアリングは、AIを操る技術というよりも、思考を言語化する技術に近づいている。

Lindy が「Lindy Assistant」を正式リリースした。Mac Mini の購入も API コストの管理も不要で、iMessage 経由で話しかけるだけで使えるクラウド型の AI アシスタントだ。高機能 AI に関心はあるものの、インフラ構築の複雑さがネックになっているユーザーに向けた、明確な解として注目を集めている。 Lindy Assistant とは Lindy Assistant は、Lindy（lindy.ai）が提供するパーソナル AI アシスタントサービスだ。創業者の Flo Crivello（@Altimor）によると、その特徴は以下の 4 点に集約される。 iMessage でチャット: スマートフォンのメッセージアプリから話しかけるだけで AI と対話できる 100 以上のアプリと連携: カレンダー、メール、Slack など多数のサービスと統合 会議・メール管理: 会議の要約、メールの返信ドラフト作成、スケジュール調整を自動化 プロアクティブな提案: ユーザーが指示する前に、時間を節約できる行動を自ら提案する 公式サイトによると、「1 日 2 時間の節約」を実現し、受信トレイ・会議・カレンダーの管理を任せることができるという。 なぜ「iMessage」を選んだのか — 仕組みと UX 設計 Lindy Assistant の最大の特徴は、専用アプリではなく iPhone 標準の「メッセージ」アプリを入口にしている点だ。iMessage という用語に馴染みのない読者向けに、簡単に整理しておく。 iMessage とは iMessage は Apple が 2011 年に iOS 5 で導入したメッセージングサービスで、iPhone・iPad・Mac の標準「メッセージ」アプリで利用できる（青い吹き出しが iMessage、緑が SMS / MMS）。Apple ID で識別されたユーザー同士がインターネット経由で送受信し、エンドツーエンド暗号化・既読通知・タップバックなど SMS にはない機能を備える。Apple デバイス以外（Android など）からは利用できない。 ...

LLM API を日本語で使っていると、英語ユーザーと比べて知らないうちに多くのコストを支払っている。この「言語税」とも言える現象を、6社・9言語の比較データで整理した投稿が話題になった。 「言語税」とは何か 日本語ユーザーは無自覚に「言語税」を払い続けている。同じ処理内容であっても、日本語で問い合わせる分だけ余計にトークンを消費し、API コストが積み上がる構造だ。 特に以下のような用途では影響が大きい。 大量のテキスト処理: 文書要約、翻訳、レビューなどを日本語で大量に行う場合 チャットボット・カスタマーサポート: 日本語ユーザーとの会話が続くアプリケーション RAG（Retrieval-Augmented Generation）: 日本語ドキュメントをコンテキストに含める場合 日本語は英語の約 1.48 倍のトークンを消費する 同じ内容を日本語で LLM に投げると、英語に比べて平均 1.48 倍 のトークンを消費するという計算がある。これは 6 社の LLM プロバイダーの平均値だ。 日本語はトークン効率が低くなる理由はトークナイザーの設計にある。英語は複数の文字が 1 トークンに対応するケースが多いが、日本語はひらがな・カタカナ・漢字が混在しており、1 文字が 1 トークンに対応するケースが多い。そのため同じ情報量でも消費トークン数が増えやすい。 プロバイダー別の日本語トークン比率 プロバイダーによって日本語処理のトークン効率には大きな差がある。 プロバイダー 日本語トークン比率（英語比） Anthropic（Claude） 1.94x Gemini 3.1 1.14x 平均（6社） 1.48x ※ 全6社の内訳は元ツイートのスレッドを参照。 Anthropic の Claude は日本語で英語の約 2 倍のトークンを消費する一方、Gemini 3.1 はほぼ英語並みのトークン効率を実現している。Claude（1.94x）と Gemini（1.14x）を比べると 1.94 ÷ 1.14 ≈ 1.7 倍 の差があり、モデル選びだけでコストが最大 1.7 倍変わるという計算になる。 コスト削減のアプローチ この「言語税」を意識した場合、以下のアプローチが有効だ。 1. プロバイダーの使い分け 日本語処理が多い用途では Gemini 3.1 など日本語トークン効率の高いモデルを選択する。Anthropic の Claude は能力が高い一方、日本語コストが割高になるため、用途に応じた使い分けが重要だ。 ...

TypeScript 界の著名エンジニア Matt Pocock が公開した「Skills for Real Engineers」が、公開 24 時間で 22,000 スター、現在は 64,000 スター超えという驚異的な勢いで注目を集めている。 GitHub: mattpocock/skills 本記事では、このスキル集の設計思想・解決する問題・導入手順を紹介する。 Skills for Real Engineers とは 「Skills for Real Engineers」は、Claude Code や Codex などの AI コーディングエージェントに「現場のエンジニアリング作法」を仕込むための Markdown ファイル集だ。 My agent skills that I use every day to do real engineering - not vibe coding. Matt Pocock 自身が毎日使っているエージェントスキルをそのままオープンソースとして公開したもので、「ノリでコーディング（vibe coding）」ではなく、現実のアプリケーション開発で機能する設計になっている。 なぜ必要なのか — AI 開発 3 大失敗パターン AI 開発で誰もがハマる以下の問題を解決するために設計されている。 1. エージェントが意図を汲まない エンジニアと AI の間の「コミュニケーションギャップ」が最大の失敗原因。エージェントは何を作りたいかを正確に理解していないまま実装を進める。 解決スキル: /grill-me — コード不要のユースケースで詳細なヒアリングを実施 /grill-with-docs — ドキュメント生成も含めた上位版 2. コードがいつまでも動かない エージェントは「動いている」と思っていても、実際には壊れていることがある。テストと実装の間にギャップが生まれやすい。このスキル集にはテスト駆動の実装フローを強制するスキルも含まれている。 ...

AI ターミナルとして知られる Warp が 2026 年 4 月 28 日にクライアントコードのオープンソース化を発表しました。発表からわずか 1 日あまりで GitHub Star が 34,000 を突破し、本記事執筆時点（2026-04-30）では 45,000 Star 超という勢いで成長しています。 Warp は単なるターミナルから、開発者と AI エージェントが協働する Agentic Development Environment（ADE） へと進化しています。本記事ではオープンソース化の概要、ライセンス構成、内蔵エージェントと外部 CLI エージェント連携、そして OpenAI が「設立スポンサー」として参加した意味を整理します。 TL;DR Warp クライアント（Rust 製）が warpdotdev/warp でオープンソース化 ライセンスは デュアル: UI フレームワーク（warpui_core / warpui クレート）が MIT、それ以外が AGPL v3 OpenAI が設立スポンサー。新しい Agent 駆動の管理ワークフローは GPT モデルで動作 内蔵コーディングエージェントに加え、Claude Code / Codex / Gemini CLI などの外部 CLI エージェントを呼び出せる クラウドエージェント基盤 Oz が Issue トリアージから Spec 作成・実装・PR レビューまでを担う Warp とは何か — Agentic Development Environment（ADE） Warp は当初、macOS 向けに登場した Rust 製の高速・モダンなターミナルです。現在は Linux にも対応しており、リッチな UI、ブロックベースの履歴、AI コマンド補完を特徴としています。 ...

この発想、めちゃくちゃ盲点だったわ。Claudeに期限切れ特許を食わせて、誰も作らなくなった商品を掘り起こし、それを1つすでに生産開始したらしい。420万件以上のパブリックドメイン特許から、シンプルに作れて売れそうなやつをAIがピックアップ。こういう新しいハックポイントを力技じゃなく出来るってのも、また新しいターニングポイントではある。 — @tanaka_yuto @gippp69 が公開した手法が話題だ。期限切れ特許を Claude に大量投入し、商品化できそうなものをスコアリングして Alibaba で製造委託、Amazon で販売するパイプラインを個人で構築した。 設計図（特許文書）のコスト：$0。製造コスト：$1.80/個。Amazon 販売価格：$11.99。 なぜ「期限切れ特許」なのか 特許は本来、発明者に一定期間の独占権を与える代わりに、発明の詳細を全て公開することを義務付けている。これが期限切れになると、詳細な製造仕様書が誰でも無料で使えるパブリックドメイン資産になる。 過去10年間だけで、米国では420万件以上の特許が失効している。失効理由はさまざまだ： 企業の倒産 更新費用（$1,600程度）の未払い 買収後の整理 事業方針の変更 大事なのは、製品が失敗したのではなく、製品を守っていた企業が消えたという点だ。需要は存在したまま、供給だけが途絶えた商品が大量に埋もれている。 1件あたり何十ページもある特許文書を人間が読んで評価するのは現実的ではない。4,200,000件など到底無理だ。だが Claude なら読める。 パイプライン全体像 USPTO Bulk Data API │ ▼ Python スクレイパー（カテゴリ・出願者規模・日付でフィルタ） │ ▼ markitdown（特許文書を Markdown に変換） │ ▼ files-to-prompt（50件ずつバッチ化） │ ▼ Claude スコアリングパイプライン（1〜10点で評価） │ ▼ Google Patents（スコア7以上の案件を詳細確認） │ ▼ Alibaba（特許図面を送って製造見積もり） │ ▼ Amazon 出品 Step 1: 特許データの取得とフィルタリング USPTO（米国特許商標庁）は Bulk Data ポータルで全特許の全文をパブリックドメインで公開している。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # patent_filter.py — 一次フィルタ FILTERS = { "status": "expired", "type": "utility", # デザイン特許は除外 "assignee_size": "small", # IBM・Samsung などは除外 "categories": [ "household", "tools", "pet_products", "office_supplies", "garden", "kitchen" ], "expired_after": "2014-01-01", "min_claims": 3, "max_claims": 25 # 請求項が多すぎる = 複雑すぎる } 大企業の特許は製造に専用設備が必要だったり、法務リスクが高かったりする。中小企業のシンプルな消費者向け製品に絞るのがポイントだ。このフィルタで約34万件まで絞り込んだ。 ...

「AIが奪うのは単純労働から」—— その通説を、Anthropic自身のデータが覆した。 Anthropicが2026年3月に発表した研究レポート「Labor market impacts of AI: A new measure and early evidence」によると、AIの影響を最も受けているのは平均より47%も所得が高い高学歴ホワイトカラーであることが明らかになった。単純労働者ではなく、プログラマーや弁護士、金融アナリストといった「知的労働の担い手」が最前線に立たされている。 レポートの概要 Anthropicは自社の大規模言語モデルClaudeの実際の企業利用データをもとに、「実測AIエクスポージャー（Observed Exposure）」という新しい指標を導入した。これは「AIが理論上できること」ではなく、「AIが実際に職場で使われている割合」を測定するもので、現実の自動化状況を正確に把握できる点が画期的だ。 分析の結果、AIの影響を最も受けているのは単純労働者ではなく、大学院卒などの高学歴専門職であることが示された。 知能の「代替」— 高所得職種ほどAIに侵食される レポートによると、AI露出度が最も高いグループの特徴は以下の通り: 平均より47%高い所得を持つ 低露出グループに比べて約4倍の割合で大学院卒（17.4% vs 4.5%） 女性比率が低露出グループより16ポイント高い 職種別のAI実測露出率で特に高かったのは: 職種 実測AIエクスポージャー コンピュータープログラマー 74.5% カスタマーサービス担当 70.1% これらはこれまで「高度な知的労働」として専門性が求められてきた領域だ。AIによって参入障壁が下がり、人間にしかできないとされていた業務が代替されつつある。 キャリアの「断絶」— 若手育成インフラの崩壊 今回のレポートで最も懸念されるのは、AIへの露出度が高い職種において、22〜25歳の若年層の採用が2022年以降で約14%低下していることだ。 この数字が示すのは単なる雇用減少ではない。ジュニア層が経験を積むための「基礎的な業務」がシステムから完全に排除されることで、次世代の専門家が育つインフラが構造的に崩壊しつつある。 かつて新卒が担っていたコードの初稿作成、顧客対応の一次窓口、データ整理といった業務は、今やAIが担う領域になってきた。その結果として、若年層が「最初の仕事」を得る機会そのものが失われている。 重要なのは、同レポートが「2022年後半以降、高露出職種で失業が系統的に増加した証拠はない」としている点だ。これはむしろ**「採用の停止」という形での静かな構造変化**を示しており、既存の就業者には見えにくい形で進行している。 階級の「強制的分断」— 新しい格差の形 AIによる格差は、従来の「スキルの高低」という軸では測れない新しい次元へと移行しつつある。 これからの格差を決めるのは: 自分の業務プロセスにAIを統合して最適化できるかどうか AIシステムへのアクセス権（ライセンス、組織のAI投資） AIを使いこなすためのリテラシーと権限 つまり、**個人の能力より「どの組織にいるか」「どのシステムにアクセスできるか」**が価値を決定するという、全く新しい分断が静かに進行している。 高スキル・高所得層こそがAI代替のリスクに最もさらされながら、同時にAIを活用できれば最も生産性が向上する層でもある。この矛盾が、新たな格差の構造を生み出す原動力になっている。 まとめ Anthropicの今回の研究は、「AI vs 人間」という単純な対立図式ではなく、雇用・教育・所得の三つの軸にまたがる構造的変容を浮き彫りにした。 特に若年層の採用減少は、単なる景気変動とは異なる「不可逆的な構造変化」の始まりである可能性が高い。一方で、レポートは「まだ大規模な失業は起きていない」とも指摘しており、この移行期にどう適応するかを考える時間はまだ残されている。 AI時代において求められるのは、AIに「代替される」か「使う側に回る」かという二項対立的な選択ではなく、自分の業務プロセスにAIをどう統合するかという実践的な問いに向き合う姿勢だろう。 参考リンク: Labor market impacts of AI: A new measure and early evidence — Anthropic Fortune: Anthropic just mapped out which jobs AI could potentially replace Anthropic Economic Index

RAGの長年の課題である「回答の網羅性の欠如」を、ベクトルDBを使わずに解決しようとする論文が登場した。2026年4月16日にarXivに公開された論文「Don’t Retrieve, Navigate」は、Corpus2Skill という新手法を提案している。文書コーパスを階層的スキルディレクトリへ事前変換し、LLMエージェントがナビゲートして回答を構築するアプローチだ。 従来のRAGが抱える課題 RAG（Retrieval-Augmented Generation）はこの数年で大きく進化し、多くの問題が解決されてきた。しかし「AIの回答が網羅的でない」という問題は依然として未解決のままだ。 従来のベクトル検索ベースのRAGでは、クエリに類似したチャンクをいくつか取得して回答を生成する。この方式の弱点は以下の通りだ。 クエリ表現に引きずられ、関連する別の観点の文書を見落とす チャンク間の文脈的なつながりが断ち切られる 広範なトピックをカバーする質問への回答が部分的になりがち Corpus2Skillのアプローチ：「検索するな、ナビゲートせよ」 Corpus2Skillは発想を根本から変える。ベクトル検索で文書を「取ってくる」のではなく、人間が目次や索引を辿るように、エージェントがコーパスの階層構造を「ナビゲートする」。 オフラインのコンパイルパイプライン まず事前処理として、文書コーパスを階層的スキルディレクトリへ変換する。 反復クラスタリング — 全文書をk-meansなどでグループ化する LLM生成サマリー — 各クラスタの内容をLLMが要約する 階層化 — クラスタをさらに上位概念でまとめ、ピラミッド構造を構築する スキルファイルツリーの実体化 — 結果を SKILL.md / INDEX.md の形式でファイルシステムに保存する この処理はオフラインで行われるため、推論時の遅延には影響しない。 推論時のナビゲーション 質問が来たとき、LLMエージェントは次の手順で回答を構築する。 コーパス全体の俯瞰図（ルートサマリー）を受け取る 質問に関連する上位ブランチを選択し、段階的に下位サマリーへ降下する 目的のノードに到達したら、文書IDを使って完全な文書を取得する 必要に応じてバックトラックし、別のブランチも探索する この探索パスが明示的に推論されるため、なぜその文書が取得されたかを追跡できるという副次的なメリットもある。 ベクトルDBが不要になる理由 従来のRAGではベクトルDB（Pinecone, Weaviate, Chromaなど）が必須だった。Corpus2Skillでは、スキルファイルツリーがその役割を置き換える。 項目 従来のRAG Corpus2Skill インデックス形式 ベクトルDB 階層ファイルツリー 検索方式 類似度検索 エージェントによるナビゲーション インフラ依存 ベクトルDBが必要 ファイルシステムのみ スケーラビリティ O(N) O(log N) 探索パスの透明性 低い 高い（明示的に推論） 文書数が10万件でも階層深度はO(log N)に収まるため、大規模コーパスへのスケーラビリティが高い点も特長だ。 実験結果 WixQAベンチマーク Wix社の企業向け顧客サポートを対象とするWixQAベンチマークで評価した。比較対象は以下のベースラインだ。 Dense Retrieval（密集検索）: 従来のベクトル検索RAG RAPTOR: 階層的サマリーを使った検索手法 Agent RAG: エージェントが検索を制御する手法 Corpus2Skillは全品質指標でこれらすべてを上回った。 ...