記事一覧

Claude Code でスキルを作って業務を自動化していると、ある日気づく。「AIはスキルの存在を『知っている』が、ちゃんと『使っている』わけではない」。そこに救いの手として登場するのが cognee-skills という考え方だ。 「知っている」と「守っている」は別物 ある非エンジニアの Claude Code ユーザーが体験談を X に投稿した。 Claude Code でスキルを作って業務を任せてたら、AI がスキルを呼ばずに「記憶で大丈夫」って判断して3回同じミス。 原因を調べたら、スキルの保存場所が設定ファイルに書いてあるのにそこを見てなかった。「知っている」と「守っている」は別物だった。 この問題への対処として取られた手順は3つ: ルール追加 — スキルを必ず呼ぶよう明示的に指示を加える 失敗パターンの記録 — 同じミスが起きないよう記録に残す 保存場所の明記 — どこにスキルがあるかを設定に明示する 全部で10分。しかしこれはすべて手動の作業だった。 cognee-skills とは この問題の根本にあるのは、スキルファイルを作っても自動では改善されないという課題だ。AI モデルがアップデートされ、コードの構成が変わり、ユーザーの要求も変化する。しかし一度書いたスキルファイルはそのまま放置されがちだ。 cognee-skills は、スキルを継続的に改善するための5ステップフレームワークとして海外で注目を集めている。 5ステップの改善サイクル 1. 取り込み（Ingest） スキルファイルをそのまま保存するのではなく、以下の情報を付与して管理しやすい形に整理する: このスキルは何を目的としているか どんなタスクパターンに対応するか 他のスキルとどう関係するか 2. 観察（Observe） スキルが実行されるたびに結果を記録する: 何のタスクに使われたか 成功したか失敗したか エラーの内容 ユーザーからのフィードバック この記録なしに改善はできない。 3. 検査（Inspect） 失敗が繰り返されたとき、蓄積した実行記録を分析して「なぜ失敗しているのか」の原因パターンを特定する: 指示の書き方が悪いのか トリガー条件がずれているのか 外部ツールとの連携が壊れているのか 4. 修正（Amend） 原因が特定されたら、スキルファイルの該当箇所に具体的な修正案を自動生成する。修正内容は: 条件の追加 手順の並び替え 出力フォーマットの変更 人間が確認してから適用することも、自動適用することもできる。 5. 評価（Evaluate） 修正後のスキルが実際に結果を改善したかをテストする。改善していなければ元に戻す。改善が確認されて初めて、修正版が正式な新バージョンになる。すべての変更履歴が残るため、元の指示が失われることはない。 非エンジニアにとっての意味 現状では、スキルの「育て方」を知っているのはエンジニアだけだ。しかし cognee-skills の考え方が広まれば、非エンジニアでも: スキルが失敗した理由を把握できる 修正案を確認・適用できる スキルの品質を継続的に高められる 10分の手動作業が、将来的には自動化されるかもしれない。 ...

ChatGPTに指示を出して、結果を確認して、また指示を出して——このループに疲れていないだろうか。「こっちが細かく指示しなくても、AIが全部やってくれたらいいのに」という願いは、すでに実現している。その名前が Manus（マナス） だ。 この記事では、Manusの全29機能を5つのカテゴリに分けて解説する。料金プランや競合との比較、業種別の活用法まで網羅する。 Manusとは何か 「AIチャットボット」と「AIエージェント」の違い まず最も重要な概念の整理から始める。 種別 代表例 動作 AIチャットボット ChatGPT / Claude / Gemini 質問→回答の1往復 AIエージェント Manus タスクを丸投げ → 自動で完結 チャットボットは「辞書」、エージェントは「秘書」だ。Manusに「東京のAIスタートアップを30社調べて、スプレッドシートにまとめて」と指示すれば、AIが自動でブラウザを開き、検索し、情報を整理し、ファイルを作って完成品を届けてくれる。その間、別の仕事をしていてOKだ。 無料で試せる 最初は招待制だったが、現在は誰でも登録できる。無料プランでも毎日300クレジット分のタスクを実行可能（月1,500上限あり）。 実力は？ GAIAベンチマーク（実際のタスクをどれだけ正確にこなせるかを測るテスト）において、ManusはOpenAIのDeep Researchに匹敵する高スコアを記録したと複数のメディアが報じている。「実務能力で世界トップクラス」という評価は多くのメディアで一致している。 第1章：Manusの全29機能 Manusには5つのカテゴリ、計29の機能がある。 コア機能（日常的に使う基本機能） ① 自律タスク実行（Autonomous Task Execution） Manusの心臓部。指示を出すだけで、AIが計画から納品まで全自動でやる。 タスクを入力すると、Manusはまず計画を立てる。「何を調べるか」「どのツールを使うか」「どの順番でやるか」を自分で判断し、ブラウザで検索したりコードを書いて実行したりしながら完了させる。全作業はクラウド上のサンドボックスで行われるため、PCには影響しない。画面を閉じても作業は続き、完了したら通知が届く。 実行例： 「この契約書PDFの要点を抽出して、リスク項目をハイライトして」 「A社の過去3年の決算資料を分析して、成長率と利益率の推移をグラフにして」 「今月の営業チームの活動データをまとめて、週次ミーティング用の資料を作って」 ② Wide Research（ワイドリサーチ） 100体以上のAIを同時に走らせて、大規模リサーチを一気にやる。 通常のAIは1つのタスクを1つのエージェントが処理するが、Wide Researchはタスクを細かく分解して100体以上のAIエージェントを同時並行で走らせる。1社調べるのも100社調べるのも、かかる時間はほぼ同じだ。 OpenAI Deep Researchとの違い： 機能 特徴 Deep Research 1つのテーマを深く掘り下げる（深さ重視） Wide Research 多数のテーマを同時に広く調べる（広さ重視） 注意点：クレジット消費が大きいため、まず10〜20社でテストしてからスケールアップするのが鉄則。最大250件まで対応。 ③ Browser Operator（ブラウザオペレーター） ChromeまたはEdgeに拡張機能をインストールすると、Manusがブラウザを直接操作できるようになる。最大のポイントは、既存のログイン情報がそのまま使えること。つまり、ログインが必要な社内ツール、CRM、管理画面も操作可能だ。 主な活用例： CTO 50人の名前・会社名・プロフィールURLを収集 ECサイトで特定商品の価格を毎日モニタリング Wantedlyで求人情報を一括収集 競合5社のX（Twitter）アカウント分析 Googleフォームへのデータ一括入力 セキュリティ面：毎回の操作で許可が必要で、全操作ログが記録される。パスワードは保存されない。 ...

NVIDIAがGTC 2026（2026年3月16日）で発表した「NemoClaw」は、OpenClawのセキュリティ・プライバシー層を強化するオープンソーススタックです。OpenClawの競合ではなく、OpenClawを包み込む構造になっており、企業や業務利用での安全なAIエージェント運用を実現することを目指しています。 本記事では、NemoClawとは何か、OpenClawとの関係、ポリシーファイルの設定方法、導入フロー、実際に触れてみての所感をまとめます。 NemoClawとは NemoClawはNVIDIAが発表したOpenClaw専用のセキュリティプラグインです。内部では OpenShell というサンドボックスランタイムを使い、AIエージェントをLinuxコンテナで隔離します。ファイルシステム・ネットワーク・プロセスをポリシーで制御し、OpenClaw単体では防ぎきれなかったセキュリティ上の問題に対処します。 構成は以下の3層です: OpenShell: 汎用サンドボックスランタイム。AIエージェントをLinuxコンテナで隔離 NemoClaw: OpenClaw専用プラグイン（セキュリティ・プライバシー層） OpenClaw: サンドボックス内で動作するエージェント本体 OpenClawのセキュリティ問題とは OpenClawには tools.deny による制限機能がありますが、アプリケーション層での制御であるため、バグや迂回経路が発見されると突破されてしまうリスクがあります。プロンプトインジェクション攻撃によるデータ漏洩や、意図しないシステムコールの実行が代表的な懸念点です。 セキュリティの4層防御 NemoClawは以下の4層でセキュリティを確保します: 層 技術 ファイルシステム Landlock LSM（カーネルモジュール） ネットワーク egress proxy + アプリケーション単位制御 プロセス seccomp + コンテナ隔離 推論 ゲートウェイ経由ルーティング 最大の特徴は「アプリ層ではなくカーネル層で強制される」点です。OpenClawの tools.deny と異なり、バグや迂回方法が発見されても突破できません。 ネットワーク制御の仕組み NemoClawのネットワーク制御は Deny by default が原則で、全通信がデフォルトでブロックされます。許可は「アプリケーション×ホスト」の組み合わせで明示的に指定します。 例えば: git → GitHub接続を許可 curl → ブロック このような細粒度の制御により、仮にエージェントが悪意あるプロンプトインジェクションを受けても、データの外部流出が不可能になります。 ポリシーファイル ポリシーはYAML形式で宣言的に記述します。読み書き可能なパス、ネットワーク接続先、許可するバイナリを定義でき、GitOpsでの運用も可能です。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # ポリシーファイルの例（概念的な構成） filesystem: read: - /workspace - /home/agent write: - /workspace/output network: allow: - binary: git hosts: - github.com - api.github.com process: allow_binaries: - git - python3 - pip このようなポリシーファイルをリポジトリで管理することで、セキュリティ要件の変更履歴を追跡し、レビュープロセスを通じて変更を管理できます。 ...

NVIDIA が OpenClaw 向けのオープンソーススタック「NemoClaw」を発表しました。これまでセキュリティ面での懸念が指摘されてきた OpenClaw に対し、プライバシー保護とセキュリティ制御を加えた形で、常時稼働する AI エージェントの運用を可能にするものです。 NemoClaw とは NemoClaw は、OpenClaw 上で動作する AI エージェントをより安全・簡単にデプロイするための NVIDIA 製オープンソースフレームワークです。 NVIDIA AI Developer の公式ツイートによると、NemoClaw は以下の特徴を持ちます: シングルコマンドでデプロイ: OpenClaw の常時稼働アシスタントを 1 コマンドで起動できる 安全なデプロイ: セキュリティ強化された環境でエージェントを稼働させられる 任意のコーディングエージェントに対応: 特定のエージェントに縛られず、さまざまなコーディングエージェントを実行可能 どこでもデプロイ可能: クラウド・オンプレミスを問わず柔軟に展開できる 無料の NVIDIA Brev Launchable でお試し環境を立ち上げることもできます。 OpenClaw のセキュリティ課題への対応 OpenClaw はこれまで、外部からのアクセスを受け付けるアーキテクチャ上の特性から、脆弱性リスクが指摘されてきました。NemoClaw はこの課題に正面から取り組み、以下の機能を OpenClaw スタックに追加しています: プライバシー保護: エージェントが扱うデータの漏洩リスクを低減する仕組み セキュリティ制御: アクセス制御やサンドボックス化による不正操作の防止 これにより、企業や開発チームが OpenClaw ベースの AI エージェントを本番環境に安心して導入できるようになります。 試してみる NVIDIA の公式ページ（https://www.nvidia.com/nemoclaw）から NemoClaw の詳細確認および Brev Launchable による無料トライアルが可能です。 OpenClaw を本番運用で活用したいが、セキュリティが不安で踏み切れなかった開発者にとって、NemoClaw は有力な選択肢になりそうです。

Okaraが「世界初のAI CMO」を発表した。Webサイトを入力するだけでエージェント群がデプロイされ、X（Twitter）やRedditでのマーケティングタスクを自律的に実行してくれるというサービスだ。 Okara AI CMOとは Okara が2026年3月に発表した AI CMO（Chief Marketing Officer）は、自社サイトのURLを入れるとAIエージェントのチームが自動展開され、トラフィック獲得やユーザー獲得のための施策を実行するサービスだ。 Today we’re introducing the world’s first AI CMO. Enter your website and it deploys a team of agents to help you get traffic and users. — @askOkara XやRedditといったプラットフォームでの相談対応やタスク実行が可能とのことで、マーケに関わる業務を幅広くカバーする。 日本のマーケターの反応 AI駆使型のスモールビジネスオーナーとして知られる @L_go_mrk 氏は、このニュースに対して次のようなコメントを投稿している。 これまじでやばいだろ。。。 OkaraがAI CMOを開発した。 XもRedditも、マーケに関することなら割となーーーーーーーーーんでも相談とタスク実行ができてしまう。 アカウントのBanリスクが怖いけど、本当にそれぐらい。 似たようなことを社内ツールで開発しようとしてたけど、それが吹っ飛んでしまった笑 「社内ツールで自前開発しようとしていたが、それが吹っ飛んだ」という反応は象徴的だ。マーケティング自動化ツールを自社開発するコストを、プロダクトとして提供しきってしまうプレーヤーが登場した、という状況を端的に表している。 AI CMOが示すエージェント時代のマーケ AI CMOが体現しているのは、タスク実行まで一貫して担うエージェント型AIの台頭だ。 従来の「AIによるマーケ支援」は、コピー生成や分析補助といったアシスタント的な役割にとどまることが多かった。しかしOkaraのアプローチは、SNSでの投稿・返信・エンゲージメントといった実際のアクションをエージェントが代替する点で一線を画す。 主な特徴として挙げられるのは以下のとおりだ。 サイトURLを入力するだけで自動セットアップ: 複雑な設定なしにエージェントが起動する X・Redditへの直接介入: 相談への返答やコンテンツ投稿を自律的に実行する 複数エージェントの協調: 単一モデルではなく「チーム」として機能する 課題：アカウントBANリスク 一方で、プラットフォームの利用規約との兼ね合いは課題として残る。XやRedditは自動化ツールによるスパム的な操作を禁止しており、AIエージェントによる大規模な操作がBANの対象になるリスクは現実的だ。 L_go_mrk 氏も「アカウントのBanリスクが怖い」と言及しており、実運用上は利用範囲を慎重にコントロールする必要がある。 まとめ OkaraのAI CMOは、マーケティングの実行業務をAIエージェントに委任する、新しい時代の始まりを告げるプロダクトだ。自前のマーケ自動化ツールを開発しようとしていた担当者が「吹っ飛んだ」と感じるほどのインパクトがある。 エージェントがSNSに直接介入する時代において、どこまでをAIに任せ、どこに人間のコントロールを置くか——そのバランス設計が、今後のマーケティング戦略の核心になってくるだろう。 ソース: @L_go_mrk on X (2026-03-17)

AI ツール「OpenClaw」を使った X（旧 Twitter）運用で、10日間でフォロワーを 1800人増やした実践的な方法をまとめた記事を紹介する。 元記事: @ichiaimarketer（いち＠OpenClawガチ勢） フォロワーが伸びない原因を「3要素」で整理する フォロワーが伸びない多くの人は次の悩みを抱えている。 毎日投稿しているのにインプレッションが伸びない ネタ切れで手が止まる たまたまバズっても、なぜ伸びたかわからず再現できない これらの原因は、以下の「3要素」のどれかが欠けていることにある。 フォロワーが伸びる条件 = 投稿数 × バズる投稿の型 × 情報密度 要素 説明 投稿数 量が必要。ただし量だけでは伸びない バズる投稿の型 スクロール中に目を止められる見やすさ・構成 情報密度 最新情報か、自分だけの1次情報（体験・実績・独自解釈）が含まれているか この3つが揃ったときだけ、フォロワーは増える。 また、現在のフォロワー数によって「いちばん効く要素」が変わる。 Aグループ（フォロワー200人以下・投稿が少ない人）: まず投稿数を増やすことが最優先 Bグループ（フォロワー200人以上・30投稿以上ある人）: 型と情報密度の最適化がカギ なぜ OpenClaw で X が伸びるのか OpenClaw は、この3要素すべてにレバレッジをかけられる点が他のAIツール（ChatGPT・Claude等）と異なる。 ① 投稿数：AIが「あなたの文体・型」を覚えたまま量産 ChatGPT や Claude でも投稿案は出せる。OpenClaw の違いは永続メモリにある。 あなたの文体、バズる型を覚えたまま量を出せる 毎回ゼロから説明し直す必要がない 2回目以降は「前回の型で」と頼むだけ ② 情報密度：最新情報を自動収集＋1次情報をいつでも引き出せる 情報密度は2種類に分けて考える。 最新情報（トレンド・ニュース）: OpenClaw のタスク機能で自動収集 1次情報（体験・実績・独自解釈）: OpenClaw のメモリに日々の気づきを蓄積し、いつでも活用 1次情報こそが差別化の核。浅い情報が溢れる中で、フォロワーをファンにするのはここ。 ③ バズる投稿の型：一度分析すれば永続的に型を量産 伸びる型はアカウントによって異なる。分析結果を OpenClaw のメモリに保存しておくと、「今日の1本」「今週の20本」を型に沿って量産できる。他のAIでは分析結果を毎回入力し直す手間があるが、OpenClaw なら不要。 具体的な方法①：「分析 → 1ポスト」の流れをつかむ まず「分析→1ポスト」の基礎フローを習得することが土台になる。 ...

AIエージェントを使った「0人会社（zero-human company）」のコンセプトが現実に近づいている。 Paperclip は、そのためのオーケストレーション基盤としてオープンソース化されたツールだ。 Paperclip とは Paperclip は「ゼロヒューマン企業」を動かすためのオーケストレーション層（orchestration layer）。 人間なしで自律的に業務が進む組織を設計・運用するための基盤として設計されている。 GitHubリポジトリ: paperclipai/paperclip リリース後またたく間にスターが集まり、2026年3月時点で 53,000スター超 を記録している。 主な機能 Paperclip が提供する機能は次の通り: 組織図（Org Charts） — エージェントの役割と階層を定義する 目標整合（Goal Alignment） — 組織全体の目標を各エージェントのタスクに紐付ける タスクの責任者（Task Ownership） — どのエージェントが何を担うかを明確に割り当てる 予算管理（Budgets） — エージェントが使用できるリソースや費用に上限を設定する エージェントテンプレート（Agent Templates） — 役割ごとの標準的なエージェント設定を再利用する これらの仕組みにより、人間のオペレーターが常時介在しなくても「自律的に仕事が進む会社」を実現できる。 クイックスタート セットアップは npx で1コマンド: 1 npx paperclipai onboard このコマンドを実行すると、初期の組織設計のガイドが始まる。TypeScript 製で、Node.js 環境があればすぐに試せる。 なぜ注目されるのか 従来の AI エージェントフレームワークの多くは、単一エージェントまたは単純なマルチエージェントの連携を想定している。Paperclip が異なるのは、企業・組織レベルの構造をファーストクラスの概念として扱っている点だ。 単なるタスクキューではなく、組織図と権限委譲を持つ エージェント同士の目標が整合されていることを保証する仕組みがある 予算制約により無限ループや暴走を防ぐ設計になっている 「AIエージェントに会社を任せる」という考えを本格的にサポートするインフラとして、エンジニアコミュニティの注目を集めている。 参考リンク paperclipai/paperclip - GitHub オープンソース化を告知したツイート（@dotta）

redis-py の Lock クラスは UUID ベースのトークンでロックの所有権を管理するが、フェンシングトークン（単調増加する数値）は提供しない。しかし、Lock クラスは do_acquire や Lua スクリプトをオーバーライドできる設計になっており、サブクラス化でフェンシングトークンを追加できる。 本記事では、redis-py の Lock を拡張してフェンシングトークンを発行する FencedLock クラスの実装例を紹介する。 前提知識：Redis の Lua スクリプティング Redis はバージョン 2.6 から Lua スクリプトの実行機能を内蔵している。EVAL コマンドで Lua スクリプトを Redis サーバー上で直接実行でき、複数の Redis コマンドをアトミック（不可分）に実行できる。 なぜ Lua スクリプトが必要か 通常、Redis コマンドは1つずつ実行される。例えば「キーが存在しなければセットし、同時にカウンターをインクリメントする」という処理を2つのコマンドで行うと、その間に他のクライアントが割り込む可能性がある： クライアント A: SET mykey value NX → 成功 ← クライアント B が割り込む余地 クライアント A: INCR counter → インクリメント Lua スクリプトを使えば、この2つの操作を1回のアトミックな呼び出しにまとめられる： 1 2 3 4 5 6 -- Redis サーバー上で実行される（他のコマンドは割り込めない） local ok = redis.call('SET', KEYS[1], ARGV[1], 'NX') if ok then return redis.call('INCR', KEYS[2]) end return nil Redis CLI での実行例 1 2 # EVAL "スクリプト" キーの数 キー1 キー2 ... 引数1 引数2 ... redis-cli EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue redis-py での実行例 1 2 3 4 5 6 7 8 9 10 import redis r = redis.Redis() # 方法1: eval で直接実行 r.eval("return redis.call('SET', KEYS[1], ARGV[1])", 1, "mykey", "myvalue") # 方法2: register_script で事前登録（推奨） # サーバー側に SHA1 でキャッシュされ、2回目以降はスクリプト本文の転送が不要 script = r.register_script("return redis.call('GET', KEYS[1])") result = script(keys=["mykey"]) セキュリティ上の注意 Lua スクリプトのパラメータは KEYS[] と ARGV[] で渡される。SQL のプリペアドステートメントと同様に、パラメータが文字列としてスクリプトに展開されることはないため、パラメータ経由でのインジェクションはできない。ただし、ユーザー入力でスクリプト文字列自体を動的に組み立てると危険なので、スクリプトは固定文字列として定義すること。 ...

takt は、Claude Code や Codex などの AI コーディングエージェントのワークフローを YAML で定義できる CLI ツールです。エージェントに単にコードを書かせるだけでなく、レビューループや人間の介入ポイントを宣言的に管理することで、品質の高いアウトプットを継続的に得られるよう設計されています。 takt とは TAKT は TAKT Agent Koordination Topology の略で、ドイツ語の「拍子・指揮棒」を由来とする名前です。オーケストラの指揮者のように複数の AI エージェントを統率するというコンセプトが込められています。 GitHub: https://github.com/nrslib/takt 言語: TypeScript スター数: 952（2026年4月時点） ライセンス: MIT 対応エージェント: Claude Code、Codex、OpenCode、Cursor、GitHub Copilot CLI なぜ takt が必要か AI コーディングエージェントを使う上で重要なのは、ワークフローの設計です。エージェントに「コードを書いて」と指示するだけでは、品質にばらつきが生じます。takt は以下の課題を解決します: レビューループの自動化: 実装 → レビュー → 修正 のサイクルを自動で回す 再現性の確保: 実行パスを YAML で宣言するため、チーム間で同じ品質プロセスを共有できる マルチエージェント対応: 異なるペルソナ・権限・レビュー基準を持つ複数エージェントをオーケストレーション 完全なトレーサビリティ: 全ステップを NDJSON でログに記録 インストールと基本的な使い方 1 npm install -g takt 設定ファイル ~/.takt/config.yaml を作成してプロバイダーを指定します: ...

「AIに言葉で指示するだけ」のバイブコーディング（vibe coding）において、どんな人が高い成果を出せるのか——CHI2026 に採択された論文の知見が注目を集めています。 バイブコーディングとは バイブコーディングとは、実際のコードを読み書きせず、AI に自然言語で指示するだけでソフトウェアを開発するスタイルです。ChatGPT や GitHub Copilot などの生成 AI の台頭により、プログラミング経験のない人でも簡単なアプリを作れるようになったことで注目されています。 しかし「コードを書かなくていいなら、誰でも同じ成果が出せる」かというと、実験結果はそう単純ではありませんでした。 CS 基礎知識がある人ほど成績が良い 論文によると、コンピュータサイエンス（CS）の基礎知識がある人ほどバイブコーディングの成績が高いという結果が得られています。 コードを一切読み書きしない状況でも、以下のような CS 的な思考が AI への指示を組み立てる上で役立つと考えられています。 問題分解の思考法: 大きな問題を小さなステップに分解する能力 アルゴリズム的な発想: 処理の流れや条件分岐を論理的に考える力 データ構造の概念: 何をどう扱うかを抽象的に把握する力 AI に指示を出す際も、「何をしてほしいか」を明確に分解して伝える必要があります。CS の素養は、そのための基盤となるわけです。 文章力が高い人ほど良い成果が出せる さらに注目すべき知見として、文章力が高い人ほどバイブコーディングの成果が高いという傾向が示されています。 その連鎖は非常に明快です。 文章力が高い → プロンプトの品質が高い → アプリの出来が良い AI に対して意図を的確に伝える「プロンプト」は、本質的には文章です。論理的で明確な指示を書ける人は、AI から意図した出力を引き出しやすく、結果として高品質なアプリを作れるということです。 意外な発見：LLM ヘビーユーザーは成績が低い傾向 今回の実験で驚きの結果も明らかになっています。LLM を普段からよく使っている人ほど、バイブコーディングの成績が低く、文章力も低い傾向があるというものです。 因果関係は断定できませんが、研究チームは 2 つの可能性を考察しています。 LLM への依存が言語化能力を低下させる: AI に頼りすぎることで、自分で言語化する力が鍛えられなくなる もともと言語化が苦手な人が LLM を多用する: 自分で考えて伝えることが苦手なため、AI に委ねる頻度が高くなる この知見は、AI ツールとの関わり方を見直すきっかけになりそうです。 まとめ CHI2026 採択論文のこの知見をまとめると、バイブコーディングで成果を出せる人の特徴は次の通りです。 要因 傾向 CS 基礎知識 あるほど成績が高い 文章力 高いほど成績が高い LLM 利用頻度 高いほど成績が低い（意外な結果） 「コードを書かなくていい時代」だからこそ、問題を論理的に分解する力 と 意図を明確に言語化する力 がより重要になる——この研究はそのことを示唆しています。 ...