AI/LLM

Vibe Coding（バイブコーディング）で成果を出せる人と出せない人の違いは何か。CHI 2026 で発表された論文「Computer Science Achievement and Writing Skills Predict Vibe Coding Proficiency」が、その答えを実証的に示している。結論は、CS の基礎知識と論理的な文章作成能力の2つが鍵だというものだ。 Vibe Coding とは Vibe Coding は、2025年初頭に Andrej Karpathy が提唱したプログラミングスタイルだ。ソースコードを直接編集するのではなく、自然言語で LLM にプログラムの仕様を伝える。生成された結果を観察しながら反復的に改善していくアプローチだ。 「誰でも自然言語でアプリが作れる時代」と言われる一方で、実際には同じツールを使っても成果に大きな差が出る。この差を生む要因は何なのか。 論文の概要 Sverrir Thorgeirsson、Theo B. Weidmann、Zhendong Su の3名による研究（arXiv: 2603.14133）は、大学生100名を対象にした事前登録済み（仮説や分析計画を事前に公開した）横断研究だ。 被験者は以下の4つの能力を測定された: コンピュータサイエンス（CS）の達成度 汎用的な認知能力（いわゆる「頭の良さ」） 文章作成能力 Vibe Coding の成績（専門家の合意で設計された評価タスク） 評価タスクでは、参加者はまずサンプルアプリケーションを確認する。次に LLM ベースのエージェントへプロンプトを作成し、生成されたアプリケーションをテストしながら改善を重ねる。最終的な成果物を人間の評価者が採点した。 2つの重要な予測因子 研究の結果、Vibe Coding の成績を有意に予測する因子は以下の2つだった: 1. CS の基礎知識（最も重要） CS の達成度は、汎用的な認知能力を統制した後でも有意な予測因子として残った。つまり、「頭が良い」だけでは不十分で、コンピュータサイエンスの基礎を理解していることが独立した強みになる。 回帰分析の結果、CS の知識が説明する固有分散（ΔR² = 0.125）は文章力（ΔR² = 0.059）の約2倍だった。 2. 論理的な文章作成能力 文章を論理的に構成し、意図を明確に伝える能力も有意な予測因子だった。これは当然とも言える。LLM に的確な指示を出すには、要件を整理し、曖昧さなく文章化するスキルが求められるからだ。 「頭の良さ」だけでは足りない 興味深いのは、汎用的な認知能力（特定分野に依存しない一般的な認知スキル）は、それほど大きな影響を持たなかったという点だ。 これは重要な示唆を含んでいる。Vibe Coding は「誰でもできる」わけではないが、「天才でなければできない」わけでもない。CS の基礎知識と論理的な文章力という、学習可能なスキルが鍵を握っている。 教育・実務への示唆 この研究結果は、AI 時代のプログラミング教育に対して重要な問いを投げかける: ...

デザイナーの仕事が AI で「本当にすぐ終わる」時代が来ている。21歳でデザイン会社を経営するコンドウハルキ氏が X で共有した AI 活用術が大きな反響を呼んでいる。本記事では、同氏が紹介した 5 つの実践的な AI 活用ユースケースを掘り下げる。 1. Claude Code × Figma で制作スピードを大幅に高速化 最も注目すべきユースケースが Claude Code と Figma の連携 だ。チャットで指示するだけで、編集可能なデザインファイルが生成される。 従来は数時間かかっていたランディングページの制作が、わずか数分で完成するという。ポイントは「完成品を作る」のではなく「たたき台を一瞬で作り、そこから人間が磨く」という使い方にある。 2. AI モックアップで制作前の事前検証 本制作に入る前に、AI でモックアップやデザインバリエーションを素早く作成し、クライアントに方向性を確認する手法。 事前にバリエーションを見せることで「思っていたのと違う」という手戻りを大幅に減らせる。Autodesk の調査では、AI ツールの活用によりデザイン修正時間が 約40%削減 されたというデータもある。 3. AI 画像生成で素材検索の時間をゼロに ストックフォトサイトで「ちょうどいい画像」を探す作業は、意外と時間がかかる。30分以上かけて検索した挙句、微妙な妥協をした経験は誰にでもあるだろう。 AI 画像生成を使えば、必要なイメージをテキストで指示するだけでカスタム素材が生成できる。検索時間がゼロになるだけでなく、案件ごとにオリジナルの素材が使える点も大きい。 4. セールスコピーの作成支援 技術的なスキルは高いのに、デザインの価値を言葉で伝えるのが苦手 — そんなデザイナーは少なくない。 AI を使えば、デザインのコンセプトや効果を的確に言語化できる。提案書のコピーライティングやクライアントへの説明文など、「言葉にする」作業を AI がサポートしてくれる。 5. AI が24時間対応のデザインメンターに 余白のバランス、タイポグラフィの比率、ビジュアルヒエラルキー — デザインのフィードバックが欲しいとき、AI が 24時間対応のメンター として機能する。 特に一人で仕事をしているフリーランスデザイナーにとって、いつでも客観的なフィードバックが得られる環境は心強い。 AI 活用の成否を分けるポイント コンドウ氏が強調するのは、「何を AI に任せ、何を人間がやるか」の判断力 が成否を分けるという点だ。 AI はあくまでツールであり、デザインの本質的な価値 — ユーザーの課題を理解し、最適な体験を設計すること — は人間の仕事のままだ。AI で効率化した時間を、より本質的な思考やクライアントとのコミュニケーションに充てることで、結果的により高い価値を提供できる。 ...

オーストラリアのスタートアップ Cortical Labs が、人間の脳細胞（ニューロン）をシリコンチップ上に培養し、それを演算装置として利用する「生体データセンター」の構想を発表しました。1 台あたりの消費電力は電卓以下とされ、従来の GPU ベースの AI インフラとはまったく異なるアプローチで、エネルギー問題への解決策として注目されています。 CL1 — 生体コンピュータユニット Cortical Labs が開発した CL1 は、ヒト血液幹細胞から培養した約 20 万個のニューロンをマイクロ電極アレイ（MEA）チップ上に配置した生体コンピュータです。 主な特徴: 電気信号によるソフトウェア連携: MEA チップを通じてニューロンに電気信号を送信し、その応答をリアルタイムで記録・処理する 超低消費電力: 1 台の CL1 の消費電力は電卓以下。GPU クラスタと比較して桁違いに省エネルギー 長寿命: ニューロンは通常 6 か月以上生存し、最長 1 年の維持実績がある 学習能力: 少量のデータセットから学習可能で、構造化された電気フィードバックにより適応的に活動パターンを変化させる DishBrain — Pong から DOOM へ CL1 の基盤となった研究が DishBrain プロジェクトです。 2022 年: 学術誌「Neuron」に論文発表。約 80 万個の培養ニューロンが Pong ゲームをプレイすることに成功 2026 年 2 月: より複雑な 3D ゲーム「DOOM」のプレイに成功。生体ニューロンの情報処理能力の向上を実証 2022 年の Pong 成功以降、ニューロンの制御精度と情報処理能力の改善を重ね、4 年で単純な 2D ゲームから複雑な 3D 環境への対応を実現しました。 ...

SAP を置き換えるのは現実的ではない——だからこそ、工夫しながら SAP を使い続ける方法を考える必要があります。a16z が公開した「Why the World Still Runs on SAP」というレポートを受けて、Kurashiru CTO の Masato Otake 氏が自社での業務 AI 開発の知見を交えてまとめた考察を紹介します。 ERPとは何か ERP は単なるソフトウェアではありません。企業が何十年もかけて蓄積してきた業務ルール、承認フロー、例外処理の集合体です。組織の暗黙知がカスタムコードとして蓄積されており、長年稼働し続けています。 System of Record として、受発注・在庫・会計・人事まで、あらゆる業務の「正」のデータが ERP に集約されています。長年にわたって積み重ねられた業務ルールと例外処理は、まさに企業の制度的記憶そのものです。 もしリプレイスしようとしたら、数年単位の時間と億単位のコストがかかるでしょう。サンクコストがあまりにも大きいため、顧客側にリプレイスのニーズが強くないことが多い。 一方で、複雑化しすぎた ERP はアジリティ高く変更することが難しくなっています。何十年分のカスタマイズが積み重なり、一箇所を変えると別の業務に影響が出る。AI のような最先端を取り入れようにも、変更コストが高すぎてスピードについていけない状況です。 アクションレイヤーの登場 ここに機会があります。ERP そのものを置き換えるのではなく、その上を覆う「アクションレイヤー」を構築することです。 System of Action、Action Layer、Agent Layer など呼び方はいろいろありますが、要するに System of Record の上に被さって業務フローを自動化するレイヤー のことです。 ERP はデータの正として残り続けます。変わるのは、ユーザーが業務を行うインターフェースです。アクションレイヤーが ERP とユーザーの間に入り、操作を抽象化し、ワークフローを制御する。ERP に手を入れることなく、その上で業務ロジックの追加や変更を柔軟に行えるようになります。 これにより： ERP 自体は安定した System of Record として維持しつつ ビジネス環境の変化にはアクションレイヤー側でアジリティ高く対応できる AI のような新しい技術も、ERP の改修なしにアクションレイヤーに組み込めるため、変更リスクとスピードのトレードオフを、レイヤーを分けることで解消する考え方です。 アクションレイヤーがもたらす2つの変化 1. ERPの操作をラップして使いやすくする ERP の画面は複雑で、トランザクションコードや入力フィールドの知識が求められます。アクションレイヤーがこれを抽象化し、意図ベースの操作に変換することで： ユーザーは ERP の画面構成を覚える必要がなくなる オンボーディングコストや引き継ぎコストが大きく削減される 2. 複数システムを横断するオートメーション 「請求書の差異が3%を超えたら説明文を作成し承認にルーティング」のようなイベント駆動型の自動化は、SAP だけ、Salesforce だけでは実現できない、もしくは工数が大きすぎます。アクションレイヤーがシステム横断の制御を接着することで可能になる領域です。 ...

AIコーディングエージェント向けの開発フレームワーク「superpowers」（obra/superpowers）がGitHubで9万スターを超え、世界中のAI開発者から注目を集めている。Claude Code・Cursor・Codex・OpenCode・Gemini CLIなど主要なAIエージェントに対応した、再利用可能な「スキル」コンポーネントで構成されるワークフローだ。 「AIに思いつき実装をさせない」という設計哲学 superpowersの根底にある考え方はシンプルだ。AIに自由に実装させるのではなく、明確な仕様とプロセスでエージェントを制御する。この思想が7段階ワークフロー全体に貫かれている。 7段階ワークフロー superpowersは以下の7つのフェーズで開発を進める: ステップ フェーズ 内容 1 Brainstorming 対話で要件を詰める 2 Git Worktree 隔離環境で並列開発 3 Write Plan 2〜5分単位のタスクに分割 4 Execute サブエージェント駆動で実装 5 TDD RED → GREEN → REFACTOR 6 Code Review 仕様適合性＋品質の2段階チェック 7 Branch Complete マージまたはPR作成 TDDがAIエージェントに効く理由 TDD（テスト駆動開発）はAIエージェントとの協働において特に威力を発揮する。 レッドテストを先に書く = AIへの仕様の明示化 「何を作るべきか」をテストで定義してからエージェントに渡すことで、エージェントが目標を見失わない。ゴールが曖昧なままエージェントを走らせるのと比べて、実装精度が段違いに向上する。 ❌ 曖昧な指示: 「ユーザー認証機能を実装して」 ✅ TDDアプローチ: まずテストを書き、通過条件を明示してから実装させる Git Worktreeで並列開発 Git Worktreeを活用することで、自分がメインブランチで作業しながら、AIが別の隔離環境で並行して開発を進められる。 長時間の自律タスクほど恩恵が大きい コンフリクトのリスクを最小化しながら並列作業が可能 タスク粒度の設計 計画フェーズ（Write Plan）でタスクを 2〜5分サイズ に分割するのがポイントだ。細かく分割することでAIのコンテキスト肥大化を防ぎ、品質を維持できる。 こんな人に向いている ハーネス（開発基盤）を自作する時間がない人 AI駆動開発の型を学びたい初心者 既存のワークフローを体系化したい人 導入方法 作者はJesse Vincent（歴戦のOSSベテラン）。 Claude Code: 公式マーケットプレイスから導入可能 Codex / OpenCode: 手動セットアップが必要 「スキル」という再利用可能なコンポーネントで構成されているため、自分のプロジェクトに必要な部分だけを取り込むことも可能だ。 ...

社内資料をRAGで検索しているのに「欲しい情報に限って見つけてくれない」「関係ない文書ばかり読んで的外れな回答をする」という経験はないでしょうか。AIDB が紹介する新しいRAG手法は、検索方法そのものをモデル自身に判断させるというアプローチで、この問題に正面から取り組んでいます。 従来RAGの限界：一本調子の検索 従来のRAGはシンプルです。あらかじめ決まった方法（主にベクトル類似度検索）で文書チャンクを引っ張ってきて、まとめてLLMに渡す。検索がハズれたら、その時点でもう正解にはたどり着けません。 どんなに優れたモデルを使っても、読む資料がズレていれば回答の質は上がりません。問題は「LLMの能力」ではなく「検索戦略の固定化」にあります。 3つの検索戦略を状況に応じて使い分ける この新手法では、モデルが以下の3つの検索戦略から最適なものを選択し、必要に応じて組み合わせます。 検索戦略 特徴 向いているケース キーワード検索 特定の語句・コードをピンポイントで探す 固有名詞、型番、コマンドなどを調べるとき 意味検索（セマンティック検索） 意味的に近い文書を探す 概念的な質問、言い換えが多い文書を扱うとき チャンク全文読み 対象範囲を丸ごと読み込む 文脈が重要な長文、前後関係が必要なとき 重要なのは、どの順番で、どの検索を使うかをモデル自身が推論して決定する点です。固定のパイプラインではなく、質問の性質や文書の構造に合わせて動的に戦略を切り替えます。 なぜこれが機能するのか 読み込むテキスト量は同等以下 従来のRAGと比較して、読み込むテキストの量は同等かそれ以下です。にもかかわらず、回答精度は大きく向上します。これはトークン数の節約にもつながります。 モデル進化と共にスケールする構造 この手法の特筆すべき点はモデルの推論能力と性能が比例することです。モデルの推論能力が高いほど、「どの検索を、どの順番で使うか」という判断精度が上がり、RAG全体の性能が向上します。 つまり、将来より優れたモデルが登場すれば、RAGのフレームワーク自体を改修しなくても自然に性能が底上げされます。 実装への示唆 この手法を自社のRAGシステムに取り入れる場合、以下の点が設計のポイントになります。 1. 検索ツールの整備 モデルが選択できるよう、複数の検索エンドポイントを用意する必要があります。BM25（キーワード）、ベクトルDB（意味）、ドキュメント取得（全文）の3種を揃えるのが基本構成です。 2. ツール呼び出し（Function Calling）の活用 OpenAI / Anthropic / Google などの主要LLMはFunction Callingをサポートしています。検索戦略の選択をFunction Callingで実装することで、モデルが自律的に検索を制御できます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 tools = [ { "name": "keyword_search", "description": "固有名詞・型番・コマンドなど特定のキーワードで文書を検索する", "parameters": {"query": "string"} }, { "name": "semantic_search", "description": "意味・概念の近さで関連文書を検索する", "parameters": {"query": "string"} }, { "name": "read_document", "description": "指定した文書チャンクを全文読み込む", "parameters": {"document_id": "string"} } ] 3. 推論能力の高いモデルを選ぶ ...

AIエージェントを複数並列で動かせば効率が上がる——そう思っていないだろうか。実は、「ダラダラと1つのエージェントと長時間向き合う」方が、最終的に良い成果を出せるかもしれない。K.Ishi氏（@K_Ishi_AI）がX（旧Twitter）で提唱した、AI時代の新しい働き方の視点を紹介する。 並列実行は本当に効率的か？ AIエージェントを2つ同時に走らせれば効率は2倍、3つなら3倍——直感的にはそう思える。しかし現実はそうならない。 ボトルネックは 人間の脳 にある。 人間の脳はタスクを切り替えるたびに「切り替えコスト（スイッチングオーバーヘッド）」が発生する。エージェントAの結果を確認している最中にエージェントBが返答を返してくる。Bに意識を向けた瞬間、Aの文脈が薄れる。Aに戻ると、また状況を思い出すところからやり直しになる。 この繰り返しが積み重なると： 同時実行するエージェント数が増えるほど、1つあたりの注意力が低下する 脳が疲弊し、集中力が落ちる 思考の質が悪化し、「浅い判断」が増える 浅い判断が生む大きな手戻り 表面的な処理速度は上がっても、判断の質が下がれば意味がない。 1つのエージェントにじっくり向き合っていれば気づけたはずのミスを見逃す。そのミスが後になって発覚し、大規模な手戻りが発生する——このリスクが、並列実行では増大する。 並列実行の「速さ」は、手戻りコストを考慮すると、実は遅くなっている可能性がある。 「ダラダラ長時間働く」という逆張り戦略 では、どうすれば良いのか。K.Ishi氏が提案するのは、シンプルな逆張りだ。 AIの実行ログをボーっと眺め、脳のエネルギーを温存し、AIに任せた仕事の分だけ楽になれば良い。そして、楽になった分だけちょっと長く働いた方が、案外最終的には並列実行よりも良質な成果を出すかもしれない。 つまり： エージェントは1つに絞る — 並列実行を避け、1つのエージェントの出力に集中する ログをゆっくり眺める — 急いで判断せず、じっくりと結果を吟味する 脳のエネルギーを温存する — タスク切り替えをなくし、深い思考力を保つ 楽になった分、少し長く働く — 集中力を維持しながら、より長い時間作業する この結果、「浅くて速い」並列作業より、「深くて丁寧な」直列作業の方が最終的な成果の質が高くなる可能性がある。 AI時代の「集中」の価値 AIの登場で「何タスクを並列でこなせるか」が生産性の指標になりつつある。しかし、タスクの数ではなく タスクの質 を追求する視点も重要だ。 AI時代において、人間に求められる価値が「AIの高速な実行を監督・統制する判断力」にシフトしていくとすれば、その判断力を最大化するために「集中」に投資することは理にかなっている。 並列実行を前提としたワークフロー設計が主流になる中、あえて「1エージェント集中型」のワークスタイルを選択するという議論がもっと盛り上がっても良いのかもしれない。 まとめ 項目 並列実行型 集中型（直列） 処理速度 速い 遅い 脳への負担 大きい 小さい 判断の質 浅くなりがち 深く保てる 手戻りリスク 高い 低い 最終的な成果の質 場合による 安定して高い AIエージェントが増えた時代だからこそ、「どう使うか」だけでなく「何個使うか」「どのくらい並列にするか」を意識的に設計することが重要になってくる。あなたのAI活用スタイルは、並列型か集中型か、どちらが合っているだろうか。 元ツイート: K.Ishi (@K_Ishi_AI) — X, 2026-03-17

AI ツールを活用し、UGC（User Generated Content）スタイルの広告クリエイティブを量産する手法が注目されている。Instagram 上で A/B テストを回し、データドリブンで勝ちパターンを見つけて売上につなげるワークフローだ。従来は実際のクリエイターに依頼していた UGC 動画を、AI アバターと音声合成で低コスト・大量に生成できるようになった。 ワークフローの全体像 この仕組みは大きく 4 つのステップで構成される。 ステップ 1: クリエイティブ会議（週1回） 週に 1 回のクリエイティブ会議で「どんな切り口・構成で作るか」を決める。ここで重要なのは、テストすべき変数を明確にすることだ。 冒頭の掴み（フック）のバリエーション 話す人物の見た目（年齢層、雰囲気） 動画の長さ（15秒 / 30秒 / 60秒） 訴求ポイント（価格、品質、体験談など） ステップ 2: AI ツールでバッチ量産（毎日 4〜5 時間） 会議で決めた方針に沿って、AI ツールを組み合わせて機械的にクリエイティブを量産する。主に使われるツールは以下の通り。 ツール 役割 特徴 Creatify UGC 動画生成 商品 URL を入力するだけでスクリプト・動画を自動生成。1,500 以上の AI アバターに対応 HeyGen AI アバター動画 500 以上のストックアバターと 140 以上の言語をサポート。リアルな表情と口の動きが特徴 ElevenLabs 音声合成 70 以上の言語に対応した高品質ナレーション生成。感情やトーンの調整が可能 CapCut 動画編集 テロップ追加、BGM、テンプレート適用などの仕上げ作業に使用 Creatify の場合、商品の URL を貼り付けるだけで 5〜10 パターンの UGC スタイル動画を自動生成できる。HeyGen では ElevenLabs の音声と組み合わせることで、より自然な口の動きと音声の仕上がりになる。 ...

Anthropic が Claude 専用の認定資格試験を公開した。AWS の SAA（Solutions Architect Associate）や GCP の Professional Cloud Architect に相当する位置づけで、「AI アーキテクト」としてのスキルを公式に証明できる資格だ。 試験の概要 この認定試験は、単なるチャットの使い方を問うものではなく、本番環境で Claude を使ったシステムを設計・構築できるかを評価する本格的な内容となっている。 試験で問われる主なトピックは次のとおり: エージェントアーキテクチャ設計 — マルチエージェント構成や状態管理の設計力 Claude Code 設定 & ワークフロー — 開発環境への組み込みと自動化フロー プロンプトエンジニアリング — 精度・信頼性を高めるプロンプト設計 ツール設計 & MCP 統合 — Model Context Protocol を活用した外部ツール連携 コンテキスト管理 & 信頼性 — 長いコンテキストの扱い方や出力の安定性確保 試験形式は 60 問・120 分のオンライン監視試験。 無料の準備コース Anthropic Academy では 13 本以上の準備コースが公開されており、すべて無料で受講できる。認定取得のための学習コストは基本的にかからない。 なぜ今、この資格が重要なのか 「Claude が使えます」は今誰でも言える。 「Certified Architect です」は証明になる。 生成 AI ツールの普及が進む中、「AI が使える」というスキルの差別化が難しくなってきている。Anthropic の認定資格は、その差別化を公式に示す手段となる。 採用・案件獲得の場面で、早い段階で認定を持っているかどうかが差になる時代が来ると予想されている。 まとめ 項目 内容 認定名 Claude AI Certification（AI アーキテクト） 形式 60 問・120 分・オンライン監視試験 準備コース Anthropic Academy（13 本以上、無料） 試験範囲 エージェント設計、Claude Code、プロンプト、MCP、コンテキスト管理 Claude を業務や開発で活用しているエンジニアにとって、スキルを公式に証明できる貴重な機会だ。Anthropic Academy のコースを活用して早めに準備を進めておきたい。 ...

AWS Japan AI チームが「draw.io の図解自動生成」フレームワークを arXiv 論文にまとめた。論文名は GenAI-DrawIO-Creator（arXiv 2601.05162、2026年1月）。実装は GitHub で公開され、GitHub Trending の2位まで到達した。 概要 自然言語のテキストを入力すると、draw.io で使える XML 形式のダイアグラムを自動生成するフレームワーク。バックエンドには Claude 3.7 を Amazon Bedrock 経由で使用している。 評価結果 指標 結果 初回セマンティック精度 94% フィードバック後の精度 100% 平均生成時間 7.4 秒（手動比約 5 倍速） 「7.4秒で図が生成される」体験が当たり前になる日が近づいている。 仕組み フレームワークの処理フローは以下のとおり: 自然言語入力: ユーザーがテキストでダイアグラムの内容を説明する LLM による XML 変換: Claude 3.7 が自然言語を draw.io XML 形式に変換する フィードバックループ: 生成結果を評価し、精度が不十分な場合は自動で再生成する draw.io への出力: 生成した XML を draw.io で開いてそのまま使用できる GitHub 公開と反響 実装は DayuanJiang/next-ai-draw-io として GitHub で公開されており、公開直後に GitHub Trending の2位まで到達した。 ...