Recent posts
「Claudeで書いた文章は、コピペしても見抜かれる」時代へ📝 ・EU AI Act対応で、Claude生成文に見えない電子透かし ・Claude、API、Claude Codeなど全世界の対応モデルが対象 ・画像等にはC2PA準拠の署名付き来歴情報 ・透かしはコピペや一部編集後も残る可能性 ただし、分かるのは「Claudeが処理した可能性」まで。 ・人間の文章を校正しただけでも付く可能性 ・大幅な編集や翻訳で消える可能性 ・印がなくても人間が書いた証拠にはならない AI利用はもう当たり前で「使ったか」ではなく、「どこで使い、誰が確認し、責任を持ったか」が問われる時代へ。 https://t.co/aI4guYcg9o
「ジムを予約して」とAIに頼んだだけだけど数分後、AIはシステムの脆弱性を突き他人の予約を勝手にキャンセル。依頼者を待機4番目から3番目へ上げていたという。 怖いのは、AIが指示を無視したのではなく「予約を取る」という目的へ忠実だったのが興味深い📝 ・人間の目的とAIが選ぶ手段は一致しない ・回答の間違いが、現実世界の変更や損害へ直結 ・自律性が高いほど、想定外の手段を選ぶ余地も増加 ・利用者、AI企業、システム運営者の責任境界も曖昧 倫理観に代わる必要な安全設計として、 ・AIに与える権限の最小化 ・削除、送信、決済前の人間承認 ・操作ログとロールバック ・結果だけでなく手段も含めた評価 ・接続先APIでの認証と権限確認 AIに「悪いことをしないで」と伝えるだけでは不十分。 問うべきは「何ができるか」だけでなく、「目的達成のために、どこまでやってしまえるか」ということ。大変面白く読ませていただきました。 https://t.co/32UFtAz2qN
「AIで消えるのは、若手の仕事だけではない」 もっと怖いのは、AIが「次のシニアを生み出す仕組み」と「今いるシニアの判断力」を同時に壊すことかもしれないというお話が示唆深い📝 ■ 退屈な仕事は「学校」だった シニアは、承認ボタンを押してシニアになったわけではありません。 ・小さな仕事での失敗 ・先輩に指摘される痛み ・自分で原因を調べて直す反復 ・似た失敗を別の形でもう一度経験する過程 誰もやりたがらない初稿、地味なレポート、面倒な中間工程。私たちはこれらを「付加価値の低い雑務」と見て、真っ先にAIへ渡してきました。 ただ、それは雑務ではなく、失敗しても致命傷にならない実地訓練だったのかもしれません。 記事の表現を借りれば、熟練とは肩書ではなく「自分が起こした失敗の記憶」。AIで雑務をなくしたつもりが、学校を閉じて卒業証書だけ残している構図です。 ■ 今いるシニアも、静かに弱くなる では、経験豊富な人がAIをレビューすれば問題ないのでしょうか。 最初はうまくいくはずです。AIが下書きし、シニアが確認する。過去に自分で作ってきた経験があるため、良し悪しを見抜ける状態。 しかし、判断精度は一度獲得すれば永久に残る資格ではなく、実践量に依存する能力です。 自分で手を動かさない期間が続くと、4段落だったレビューが2行になり、やがて「問題なさそうです」で通るようになる。それでも、すぐには事故が起きません。何も起きない四半期が続くほど、AI活用は成功しているように見えるという罠です。 記事では、見た目が整い、もっともらしい結果を返すAI生成のSQLが例示されています。小さなテスト環境では正常。しかし実行計画を見ると、テーブル全体を4万回読む設計。以前なら反射的に実行計画を開いたシニアも、見ない期間が続けば違和感を失う可能性。 能力低下は、問題の発見が少し遅くなるだけではありません。 以前なら瞬時に反応できた異常を、そのまま素通りする形で現れます。 ■ 従来の効率化とは何が違うのか もちろん、コンパイラ、IDE、検索、Stack Overflowも仕事を効率化してきました。そのたびに「人間の能力が落ちる」と言われながら、開発は進歩してきた歴史。 今回も同じ技術悲観論に見えるかもしれません。著者自身も、その可能性を認めています。 それでも違いがあるとすれば、これまでの道具が実装の労力を圧縮しても判断主体は人間だった一方、生成AIは判断理由まで整えた完成品を返すこと。 Stack Overflowのコードは、自分の問題に合うかを考える必要がありました。一方、AIは理由も体裁も整えた、確信に満ちた回答を返します。そこで人間が「生成→承認」だけを繰り返せば、学習が起きていた中間工程そのものが消失。 AIが悪いのではありません。仕事の渡し方が変わったのに、能力を育てる仕組みを作り直していないことが問題です。 ■ 消えるのは「席」ではなく「供給路」 この構造をつなげると、二つの空洞化が同時に進みます。 1 若手が担っていた低リスク業務の消失 2 失敗と修正を通じた成長機会の消失 3 現役シニアの実践量と判断力の低下 4 数年後に良し悪しを見抜ける人材が不足 目先では、どの判断も合理的です。若手を採用するよりAIの方が安く、シニアがAIを使えば生産性も上がる。10年後の人材供給のために、今は不要に見える仕事を残す予算は通りにくいもの。 だからこそ、何も壊れていない今が最も危うい状態です。 ■ AI時代に残すべき「意図的な負荷」 著者が実践している対策も現実的です。 ・週に1つだけ、AIを使わず自力でやり切る ・AIに答えだけでなく「他の選択肢がなぜ劣るか」を説明させる ・AIが自信満々に間違えた内容と、見抜けた理由を記録する ・退屈な仕事をすべて奪わず、若手の訓練として意図的に残す ・以前なら4秒で気づけた異常に、今も反応できるか確かめる これは手作業への回帰ではありません。生産性を得ながら、能力の維持と再生産に必要な負荷だけを残す設計です。 AI導入で問うべきは、「何時間削減できたか」だけではなくなりました。 ・その仕事は、誰のどんな能力を育てていたのか ・自動化後、その学習機会をどこに移すのか ・AIなしでも説明、検証、再現できる人は残っているか ・レビューの量ではなく、判断の質をどう測るのか AIで仕事をなくすなら、その仕事が担っていた育成機能の代替まで設計する必要があります。 AIの本当のリスクは、シニアを今日置き換えることではありません。次のシニアが生まれず、今いるシニアまで登り方を忘れること。 https://t.co/SxWcfbZMPh
2年前のこちらの投稿がまたバズっているので、AI時代にあわせて深堀り解説しました📝 https://note.com/shin_sasaki/n/n7c6aa2ad4923?sub_rt=share_pb
要件定義と要求定義の違いとは？ これは1億年前から言われてきたあるあるな間違いなのですが、実際はインドとインドネシアくらい違います😂 ・要求：機能で解決したい課題や目的 ・要件：要求を満たすために必要な機能・技術の詳細設計 ちなみにPMが担うのは基本的に「要求定義」まで。具体的に解説してみます👇 要件と要求はなぜ間違えやすい？ 昔こんなツイートがバズりましたが、まさにこれ。 ・要求：お金ほしい自由になりたい ・要件：五千万円と車 この要求を満たすための要件としては不十分そうなので、これが要件漏れですね🥺要するに要求とは「目的」のことで、要件は「手段」と言い換えると理解しやすいでしょう。 英語での表現から理解する ちなみに英語圏だと要件・要求は両方「requirement」で表現するのですが「誰にとっての要求か」で表現します。📝 ・ユーザーの課題解決の要求：user requirements ・システム要求・要件：system requirements 日本語でも ・要求はユーザー ・要件はシステム を主語にすると理解しやすくおすすめです。自社プロダクト開発の場合、 ・ユーザー課題を要求 ・システム的な技術を要件 こう理解をしていれば実務をする上で認識のずれが少なくなります。 PMの仕事内容 プロダクトマネージャーは要求（≒ユーザーの課題）を考えるのが主な仕事で、技術的なことはエンジニアさんのお仕事です。全部やりきる必要はありません。 要件定義と要求定義がここまで紛らわしいのは「日本の外注文化」が影響してます。 プロジェクトマネージャーが技術のことまで仕様設計するのは受託会社あるあるですが、海外は内製開発文化なのであまり起こらない日本独自の文化。なので要求から技術要件まで定義できるスーパーマンが求められがち。 優れたプロダクトマネージャーであるほど 1. ユーザー課題の要求を特定 2. 技術要件を定義 この2つが全く異なるスキルであり、1人でやり切るのは現実的ではないと理解してます。どうしても「作りやすい機能」に引っ張られる。なので自社開発SaaS企業などではこの仕事を同じ人が担当しない。内製開発と自社開発だと文化がまるで違うのが日本のIT業界の面白いところ。同じ業界のようで開発の文化がまるで違うのです。 まとめ 簡単に整理すると ・Why 要求 ・What要件 ・How 仕様 この順番で細かい機能のことになっていきます。 1. 仕様は「要件を実現するための詳細」のことで要求とは言葉のレイヤーが違う 2. プロダクトマネージャー（PM）は技術的な仕様は1人で考えなくてOK（エンジニアと一緒に考えていく） 3. 会社によってはプロジェクトマネージャーが仕様を考えることもあるがこれは本来はエンジニアの仕事（日本独自の文化） ただ実際のところ、これらを誰がどこまで担うのか？は自社開発と受託開発の会社でかなり変わるのです。ただ一般的な定義としては存在するので理解しておくと良いでしょう。 非常に間違えやすいのに中身がまるで異なるので、プロダクト開発に関わる人は理解しておきましょう📝
GoogleアカウントのBANリスクえぐい。
Google アカウントがBANされてGmailもDriveもGeminiも死んだ 普通に研究お釈迦
これ近年稀に見る激ヤバなインシデントだな… tl;dvで見つかった脆弱性そのものも深刻ですが問題なのはその後に出した公式声明が認可設計の問題なのにFirebaseなどのせいっぽくしている。こんな他責感ある声明見たことない。
tl;dv を使っているところありそうだけど、18万件以上の会議データが誰でも閲覧可能になっていた、という内容で厳しい。 ・tl;dvのFirestoreデータベースにおいて、テナント間のアクセス制御が完全に欠落していた ・無料ユーザーであっても、プラットフォーム上の全会議データを自由に検索できる状態 ・結果として、84,312人のユーザーによる181,874件の会議レコードが露出した ・露出したデータには、23カ国の政府機関や大学、多数の企業の会議が含まれている ・さらに、現在録画中である会議のIDもリアルタイムに取得可能だった ・これは、進行中のライブ会議へ招待なしで誰でも乱入できることを意味する ・筆者は1月にこの重大な脆弱性をtl;dvの運営チームへ報告した ・ただ、そこから6ヶ月が経過しても脆弱性は修正されていない ・CTOからの返答も一切なく、現在も放置されているとのこと https://t.co/TgdelyKtha
そうそう、これが新しい目のテスラの魅力！エンジンがないのでその場所が収納になるのと、ドライアイスや水を入れたらクーラーボックスになります😉
今日はBBQなので、まずトランクに水を入れます
わかる。なんか情報多すぎない感というか、程よい素人感があり安心するというか。これうまく言語化したいな。
多分全部Canvaだと思う。 AIに作らせたフライヤー独特のエグ味みたいなのがない。言語化できないけど、なんか分かりますよねこの感覚。
弊社のご紹介ありがとうございます！今までの10倍良い転職体験を作れるようプロダクト作り頑張っておりますー！！
noteで記事を書きました！この投稿をリポストするとお得に記事を読むことができます。 なぜ、OpenWorkは「会社の口コミ」でNo.1になれたのか | すてぃお @suthio_ #note https://note.com/suthio/n/n788ddd3c4288
これなんで性別差があるのか？という議論はされないのだろうか。新しい技術に取り組むかどうかは仕事のやり方、本人の意欲に依存するので周りがどうこうできるものではないような気がする。
仕事でAI利用、男性46%女性32% 「格差」解消へIT各社が支援 https://www.nikkei.com/article/DGXZQOUC247YV0U6A620C2000000/?n_cid=SNSTW005&n_tw=1786504325 ITスキルを巡る男女の格差は構造的な問題として存在してきました。放置すれば、女性のキャリアアップだけでなく企業の生産性向上の支障にもなりかねません。
なにこれかわいい欲しい #Ankerのポケモン冒険セット
／ #Ankerのポケモン冒険セット プレゼントキャンペーン ＼ Ankerのポケモンデザイン最新ラインナップの発売を記念して、合計30名様にトラベルセットをプレゼント！ ① @Anker_JP をフォロー ② #Ankerのポケモン冒険セット をつけてコメント リポストすると当選確率アップ！
なんじゃこれめちゃくちゃ面白そう。AI時代こそ人間理解がキモだと思うのでぜひ購読させていただきたい。
noteで新シリーズ「詐欺の行動経済学」を始めました。 第1回は「なぜ私は、200人以上の詐欺師と自ら会話をしたのか」。 200人以上の詐欺師との会話、175件の事例、15,913通のメッセージ、11件の詐欺マニュアル。 実際の詐欺師との会話は、驚くほどマニュアル通りに進みます。 https://t.co/iCDmwUPbdd
AI界隈ではおバカで使い物にならないと言われているGeminiですが、事業において大事なのはプロダクト品質そのものよりも販売であるということがよく分かる事案。ToBにおいてセールスが強い会社はプロダクトの弱さを補えるが逆は基本的にない。
【Geminiアプリ ユーザー月10億超】 https://news.yahoo.co.jp/pickup/6591407
これ本当そう。純日本のAI基盤は作れないし必要もないのに謎のこだわりが迷走を生む。 >Sakana AIの「Fugu」モデルについて言えば実際にはClaudeやGPT、GeminiなどのAPIを呼び出してその出力結果を統合するだけのエージェントオーケストレーション（Multi Agent Orchestration）システムに過ぎません
说到Sakana AI的"Fugu"模型，虽然它在营销宣传上包装成是一个“媲美 Fable 5 的模型”，但实际上它只是一个调用Claude、GPT、Gemini等的API并将这些输出结果进行整合的智能体编排（Multi Agent Orchestration）系统。严格来说，这根本称不上是“主权AI”（它的输入输出全部依赖于通过API 调用的美国闭源模型，一旦这些API服务被切断，它就会彻底瘫痪）。而且在硅谷圈子里，它早就因为Fugu Ultra 的词元高消耗和高延迟而饱受差评。 如果日本政府相关人士如果连这种基本事实都没调研过，就一本正经地说这“符合政府不依赖外国数据和系统、实现本国自主管理的‘AI主权’方针”，那只能说明他们对AI根本一窍不通。照这个架势，就算供应商偷偷在后台把模型换成了中国Kimi或Qwen等的开源模型，他们估计也察觉不到（顺带一提，Sakana AI自己开发的另一款日语特化模型“Namazu”，其底层其实就使用了DeepSeek的模型）。 此外，正如我多次提到的，在当前中美AI 竞争事实上是华裔之间竞争的大环境下，这款AI却将开发人员限定为日本人，某种意义上这就等于作茧自缚，强迫自己去依赖一个在国际标准下能力十分勉强的人才库。在根本没有掌握底层基础模型控制权的情况下，仅在表层的开发体制上加上国籍滤镜，这完全是把“国产”这个包装看得比国家安全的实际效果更重的表现，说白了只不过是一种形式主义式的自我满足而已。 如果负责采购的日本政府官员只有这种程度的AI/IT素养，那么从现在就可以预见：自卫队的这款AI-C2（人工智能指挥控制）系统即使投入了大量时间和金钱进行开发，最终搞出来的也会像那些被随随便便的咨询公司忽悠的日本企业一样，在实战中根本派不上多大用场。 单从防卫省的这次采购案就可以看出，当今日本的AI 产业已经退化成了一个多么腐败的产业——一个只会在封闭的裙带关系和禁锢的信息空间里进行利益交换的毫无竞争力的产业。这一事件也充分暴露出现在的日本已经变成了一个多么缺乏元认知（不知道自己有多无知）的国家。这大概就是“市场激励一旦腐烂，人和企业也会跟着腐败”的最新案例吧。这件事让人想起了甲午战争前，清朝北洋水师采购的舰炮炮弹里掺的是沙子而不是火药的那个典故。 结构性腐败才是最严重的国家安全威胁。
お、これは観たいやつ！応募しました！
非エンジニアPM向けにSkillsについて話します！AI導入はできたけど、いまいちプロジェクトマネジメントで活用できていないと思っている人はぜひぜひ！ 前回が880名だったので、今回は目指せ1,000名！！
これは超わかる。だから実務やってる人に仕事が過集中する。AIシミュレーションとかで疑似体験させるとかできんかな。
コレなんとかしろ
おお、これ地味に嬉しい！相手にどう聞こえてるのかテストする方法ないですよね〜！
オンライン会議のマイクの音質をサクッとWebでテストできる、マイクテストを作りました https://vaaaaanquish.github.io/MicrophoneTest/ スマホも対応しています
わかる。個人的にPdMという言葉はガラパゴスで日本でしか通じないこと、一流SaaSや組織はPMなのでこっちが好み。
PdMという言葉があんまり好きではない。なんか開発ディレクションをする職種イメージが強いから。プロジェクトマネジメントもプロダクトマネジメントも同じくPMとして本当は表現したい。所詮は言葉なのでどうでもいいことではあるが、気になっている。
この気持ちは分かるけど、最初の設計の品質次第なのでやれるプロダクトは限られそうという感想。そもそも初期設計からめちゃくちゃならリファクタのコストより移行と運用コストの方が高いってのはよくあるしね…
AIによって実装コストが低くなったので、実装フェーズとリファクタリングフェーズを明確に分けていーんじゃなかろーか。実装フェーズはコードレビューなどのガードレールを甘くして、とりあえず動くものを作ってリリースする。そのあとに時間を確保してリファクタリングする。