くのーる@AI x AppSheet 専門エンジニア | 株式会社フロント・ワークス 代表取締役

新サービスはじめました！ GWS, GAS, AppSheet 専門の業務用クラウド アプリ開発 & IT, DX 伴走支援サービス「Fuwapp」 (fuwapp.com) IT でこの社会のあらゆる業務を「ふわっと軽くする」を使命に挑戦しています！フォローいただけたら大変嬉しいです！ よろしくお願いいたします！

突然ですが、来週の金曜は「AIデザインの学校」で、くのーるさん（@Knorr_CS）による特別出張セミナーを開催！！！😍AI時代のデザイナーにはゼッタイに欠かせない、超有益な内容になってます✨️生徒のみんな、ドキドキしながら楽しみに待っててね🤤 #AIデザインの学校

@waku2244 ありがとうございます！！！ AI も活用して、さらに加速させていきます！

@Knorr_CS 新サービス「Fuwapp」リリースおめでとうございます🎉 GWS/GAS/AppSheetの専門サービス、業務効率化に期待しています✨

新サービスはじめました！ GWS, GAS, AppSheet 専門の業務用クラウド アプリ開発 & IT, DX 伴走支援サービス「Fuwapp」 (fuwapp.com) IT でこの社会のあらゆる業務を「ふわっと軽くする」を使命に挑戦しています！フォローいただけたら大変嬉しいです！ よろしくお願いいたします！

@waku2244 いままで人では難しかった、効率化 x 品質向上 が AI で実現できてハッピーです！！！

@Knorr_CS 就業規則管理にAIを活用する時代が来ましたね！管理コスト削減と正確性向上が期待できそうです😊

就業規則の管理は、AI で完全に変わります。 自社で編み出した AI ネイティブな運用形態を公開します。 # 1. 多くの企業が直面している労働法改正への対応 ここ数年で押し寄せた労働法改正をざっと上げてみると ・2022/4 パワーハラスメント防止措置義務化 ・2024/4 専門業務型裁量労働制 改正施行 ・2024/11 フリーランス保護法 施行 ・2025/4 育児・介護休業法 改正施行 第 1 段階 ・2025/10 育児・介護休業法 改正施行 第 2 段階 ・2026/10 カスタマーハラスメント防止措置義務化 これだけあります。 改正が続くと、就業規則のメンテナンスにかかる経営者・担当者の負担は大きいですよね。 しかも難しいのは: ・1 つの改正が複数の規程に影響する ・給与規程と育児介護休業規程など、規程同士の内容が連動している ・別規程・労使協定までセットで見直す必要がある これを法令遵守のもと、完璧にメンテし続けなくてはなりません。 弊社のような中小企業には大変すぎる作業です。 # 2. 解決策: 就業規則を「育つ仕組み」にする この課題を AI で解決できないかを考えました。 ポイントは、二つになります。 ① GitHub でファイルを管理する GitHub というファイル管理サービスを使って、就業規則を「専用フォルダ」で保管します。 エンジニア向けのツールという印象がありますが、いまや法務・労務分野でも世界的に使われ始めています。 ・変更履歴が全部残る (誰が・いつ・何を・なぜ変えたか) ・過去の状態にいつでも戻せる ・経営者・社労士・労務担当者が同じ場所を見て議論できる ・社内限定 (Private) で運用できるので機密性も保たれる ② AI を「役割分担した調査チーム」として動かす ここが革新的なポイントです。 1 つの AI に全部任せるのではなく、Claude Code というツールで、AI を「専門役割を持った複数のチーム」として並列に動かします (AI オーケストレーションの構築)。 人間でいうと: ・法令調査担当 ・既存規程の整理担当 ・ダブルチェック担当 ・ギャップ分析担当 それぞれの AI が並行して仕事をし、お互いの結果を検証しあって最終アウトプットを出します。 この仕組みにより、AI 単体だと起こりがちな「思い込みによる誤り」を抑え、一次ソース付きの信頼できる成果物が出せます。 # 3. 実際に弊社がやっている 4 つのステップ こうして以下のステップで、AI をつかった最新の管理手法を構築することができました。 就業規則を自動的にメンテし続ける仕組みになります。 ステップ ①: 公的なお手本を集める 厚生労働省は「モデル就業規則」を毎年改訂版で公開しています。 これを骨格にして自社の就業規則を組み立てる「テンプレート先行」アプローチが基本です。 担当 AI が一次資料を取りに行き、章構造・必須記載事項・最新の法改正反映状況を整理してくれます。 合わせて: ・育児・介護規定例 ・テレワークモデル・副業・兼業ガイドライン ・労使協定の最新様式 ・直近 3 年の労働法改正動向 といった一次公式情報を網羅的に取得します。 ステップ ②: 自社の固有運用を体系化する 会社ごとの「ここはうちの独自運用」というポイントを、別の AI が体系的に拾い出します。 例えば: ・給与計算期間 ・賞与の支給タイミング ・事業部ごとのコアタイム設定 ・独自手当 ・申請フォーム運用 など、お手本には書かれていない自社らしさを抽出します。 ステップ ③: 別 AI でダブルチェック ここが安心ポイント。 ステップ ①, ② の結果を、別の AI チームが別視点で検証します。 日付・改正内容・引用元 URL に矛盾がないか、抜け漏れがないかをチェック。 「AI に任せると不安」を取り除くための仕掛けです。 ステップ ④: ギャップ分析 → 改定案 公的なお手本と自社の運用を突き合わせて: ・お手本にあって自社にないもの → 採用検討 ・自社にあってお手本にないもの → 残すか判断 ・両方にあるが内容が違うもの → どう調整するか を分類し、それぞれにアクションを付けて整理。 最後は社労士の専門確認を経て、就業規則をアップデートします。 # 4. これからの就業規則管理 この仕組みを組んでおけば、今後は新しい法改正が公布されたら、AI に「この改正の影響を受ける規程をすべて洗い出して、改定案を出して」と頼むだけ。 数分で、影響を受ける規程それぞれに改定提案が並びます。 社労士の専門確認 → マージ → 社内周知 → 労基署届出。 つまりめちゃくちゃ運用が、楽になります。 これが弊社における、これからの就業規則メンテナンスの標準です。 詳細など興味がある方はお気軽に DM ください～

@waku2244 ありがとうございます！！ 全力で取り組んでまいります！ 💪🔥

@Knorr_CS 「Fuwapp」のサービス開始おめでとうございます✨業務をふわっと軽くするという発想、とても素晴らしいですね。DX推進の伴走支援、多くの企業の助けになりそうです😊

@amami_kai7148 リプライいただき、ありがとうございます！ いままでだと「本当はこうするのが理想なんだけど、いまは時間がなくてできないんだよな、、」というビジョンは描けても実際に工数を掛けられない場面が多かったのですが、それを AI 活用で叶えられるようになってきたのでハッピーです！ 笑

@Knorr_CS これを実際にやってる会社があると思うと、うちももっと変わらないとな…と感じます。 微力ですが、自分もAI推進していきたいです。

素敵すぎてます 安直に声の大きい事例や コンサルの進言を鵜呑みにしちゃうんじゃなくて 他社やお手本と自社との比較差分を可視化して 自社にとってどうなのか？って 自分たちで、やるやらないを決めるの大事…

@mhzk_tw zukamiho さん、ありがとうございます！！ そのようなコメントをいただけて大変嬉しいです。 「やるの？ やらないの？」は自分たちの頭でしっかり考えていきたいですね！

Introducing GPT-5.5 A new class of intelligence for real work and powering agents, built to understand complex goals, use tools, check its work, and carry more tasks through to completion. It marks a new way of getting computer work done. Now available in ChatGPT and Codex.

# Vercel 事故から逆算して考える、AI バイブ コーディング時代 (Claude Code 等) における" どこにシステムを乗せるか" 今回の事案で改めて感じたのは、クラウド/PaaS 選定の段階で "すでに事故率が決まっている部分" が思ったより大きい、ということ。 個人的には、ホスティングには Google Cloud を選んでいます。その理由を、今回の事故から逆算する形で書きます。参考になるところがあれば幸いです。 ※ ちなみに AWS でもまったく問題ないです ■ 今回の事故の要点 攻撃経路は、基盤クラウドが破られたのではなく、Vercel 従業員 → 外部 AI ツール → Google Workspace → Vercel 内部システム、という流れです。 つまり "基盤クラウドの強度" とは別のレイヤー、PaaS 事業者自身の内部運用とコントロールプレーンが攻撃面になったわけです。ここが今回の構造的なポイント。 ■ ここで効いてくる 2 つの視点 1. 事業者の防御力の差 (土台の高さ) どのクラウド事業者に乗るかで、利用者が頑張る前の土台そのものが違います。 2. 経由する事業者の数 (信頼境界の数) 多くの PaaS 事業者は、下に AWS などのクラウドを使っています。つまり "基盤側" は強い。しかし PaaS 事業者自身の内部システム・管理画面・従業員運用・サプライチェーンは、独立した別の信頼境界です。事業者を 1 枚挟むごとに、攻撃面が 1 つ増える。 クラウド選びは "基盤の強度 × 経由する事業者の数" の掛け算だと考えています。 ■ なぜ Google Cloud なのか この 2 軸で見たときに、Google Cloud を直接使う選択がかなり効きます。 ・ゼロトラスト (BeyondCorp / BeyondProd) の発祥地 いま業界標準となっているゼロトラストを、自社で実践 → 製品化してきた側です。セキュリティモデルの源流の一つが、そのまま土台に入っています。 ・物理 ~ ハードウェアまで自社で固めている 独自設計のデータセンター、サーバーに搭載される専用セキュリティチップ (Titan) によるファームウェア検証まで、クラウドの "下側" を自社コントロール下に置いています。 ・暗号化がデフォルト 保存時・転送時・内部ネットワーク通信まで標準で暗号化。利用者が意識しなくても担保される領域が広い。 ・Google 自身の運用実績 物理セキュリティキーを社員全員に配布して以降、フィッシングによる社員アカウント乗っ取りがゼロになった、という有名な実績があります。10 億人規模のサービスを運用してきた会社の実戦経験が、そのまま反映されています。 ・主要コンプライアンスを網羅 ISO/IEC 27001/27017/27018、SOC 1/2/3、PCI DSS、HIPAA、FedRAMP High、GDPR、日本の ISMAP までカバー。"第三者が厳格に見ている" 範囲が広いクラウドです。 ・Mandiant (世界トップクラスのインシデントレスポンス企業) が Google 傘下 ちなみに今回の Vercel 事故の調査にも、この Mandiant が入っています。世界中のインシデントで名前が挙がる会社が Google 内部の知見と直結している、という事実はそれなりに重い。 そして、Google Cloud を直接使うと、間に挟まる PaaS 事業者のレイヤー = もう 1 つの信頼境界を減らせます。 "基盤強度が高い × 経由事業者が少ない" の両取りができる、というのが選定理由の核です。 ■ 土台を選んだら、あとは "弱い構成を選ばない" その上で、自分がアプリ側で意識している設計指針はシンプルです。 ・秘密値は "環境変数に平文で置かない" (専用のシークレット保管サービス経由で扱う) ・DB 接続はパスワードレスにする (IAM 認証で "そもそもパスワードを発行しない") ・DB は閉域ネットワーク内のみ。本番では公開 URL を無効化し、公開面を独自ドメイン一点に絞る ・サプライチェーン防御 (自動実行スクリプトはデフォルトブロック、依存更新は公開から数日のクールダウン、CI で脆弱性監査を強制) ・監査ログはクラウド側とアプリ側の二層で残す ・アプリ層は "書ける経路が安全なものしかない" 状態にする (生 SQL が書けない、バリデーションを通さないと入力を触れない、認証は大手 IdP 委譲、認可は RBAC + 招待制) つまり、"頑張って守る" ではなく "危ない書き方ができない" 側に、土台もアプリも寄せていく。 ■ 結論 どのクラウドでも、運用ミス・サプライチェーン攻撃・インサイダーリスクはゼロにはなりません。 だからこそ、以下の 3 つを同時に効かせたい。 ・土台は世界最高水準のセキュリティ組織の肩に乗る ・経由する事業者を減らして、信頼境界の数を減らす ・漏れて困るものを、そもそも持たない設計にする AI コーディングでデプロイ速度が上がった今こそ、"どこに何を置くか" より前に、"そもそも誰の上に乗せるか" と "そもそも何を持たない設計にするか" を先に決めておきたい。 土台の差は、土台の差として残ります。

# Vercel で情報漏洩の可能性 (2026/4/20 事案) Claude Code でバイブコーディングすると、デプロイ先の候補として Vercel が提案されます。 つまり「Claude Code でかんたんに Web アプリ作ってみた」系のアプリの多くは、半自動的に Vercel 上で稼働しています。 そのサービス側で今回、情報漏洩の可能性がある事態が発生しました。 [Vercel 2026年4月セキュリティインシデント] vercel.com/kb/bulletin/ve… ■ 何が起きたか Vercel 従業員が使っていたサードパーティ AI ツール「Context.ai」が侵害され、そこから従業員の Google Workspace アカウントが乗っ取られました。攻撃者はそれを足がかりに Vercel 内部システムへ侵入。Vercel は複数のセキュリティ企業・法執行機関と連携して調査継続中です。 ■ 漏洩した可能性があるデータ ・環境変数のうち「Sensitive (機密)」マーク "未" 指定のもの (API キー、DB 接続情報、従業員情報などを含む可能性) ・一部顧客の Vercel 認証情報 (対象企業には Vercel から直接連絡済) ■ Vercel ユーザーが今すぐやること (公式推奨 6 項目) 1. アカウント / 環境のアクティビティログを確認し、不審な活動をチェック 2. 環境変数をローテーション (特に Sensitive 未指定の API キーから優先的に) 3. 今後は「機密環境変数 (Sensitive Environment Variables)」機能で秘密値を保護 4. 最近のデプロイメントを点検し、不審なものは削除 5. デプロイメント保護を最低「Standard」以上に設定 6. デプロイメント保護トークンをローテーション ■ 今回の事案で改めて確認したい基本 ・秘密値は必ず Sensitive 指定で登録する ・.env を Git リポジトリにコミットしない ・API キー / トークンは定期的にローテーションする ・AI が生成したコードは必ずセキュリティ観点でレビューする AI は「作る速度」を劇的に上げましたが、「運用する責任」は何も変わっていません。 ■ これは Vercel 固有の話ではない Web 公開の瞬間から、API キーや顧客データといった資産は、外部に晒されるリスクがあります。 今回の起点は Vercel 本体ではなく、「従業員が使っていた外部 AI ツール」でした。 どの PaaS / SaaS を使っていても、サプライチェーン攻撃のリスクは常に存在します。 AI で開発が楽になった今こそ、「誰がどこから入ってくるか」を想像できる運用セキュリティへのアップデートが必要です。

@tanakaryo_ask 意識したいポイントですね！

@Knorr_CS 与えるコンテキストによってアウトプットが変わる点、重要ですね。

「コードレビュー」に限らず、AI は善悪や正誤を問わず「ユーザーの味方」側に倒れる性質がある。 つまり与えるコンテキストによって、ユーザー自身のバイアスが AI にかかる。 公平・中立的な意見や回答を求めたいときには、この性質を理解しておく必要がある。 「他者から提供される AI によるアウトプット」についても、バイアスがかかっている可能性があることは意識したほうが良い。

@denryoku_shisyo ありがとうございます！！ ドライブ日和でした☀️

@Knorr_CS わんちゃんかわいいですね！天気が良くて気持ちよさそうですね。

ドライブデート🐶 良い天気！

【第2回AI Ops採用勉強会のお知らせ📢】 前回30名ほどの方に応募いただき、熱量高く盛り上がったAI Opsイベントですが、早くも第2回を開催します！ ClaudeやGemini使ってる方、AIを採用に取り入れたい方、ぜひお待ちしてます！ 🗓️ 日時： 2026年4月23日（木）19:00–21:00 📍 場所： ANOABSHO（港区） 💴 参加費： 無料（会場でのドリンク・軽食あり） 📋 タイムライン： 時間内容 19:00〜19:10 オープニング趣旨説明 19:10〜19:40 LTセッション（3名 各最長10分） 19:40〜21:00ネットワーキング・交流会 🎤 LT： ・Aさん｜大手スタートアップAIOps採用推進者 ・内川 礼｜タンデムラボ代表取締役社長 ・清遠 弘樹｜株式会社スタートアップクラス 執行役員 VP of Revenue 📝詳細お申し込みはこちら luma.com/h7wdkvm1

@hiroyuki_kadosa マニュアル乗りです🙌

@Knorr_CS マニュアル車ですか！？

@new_r2d クラファン！！ 🤣 握手券 (お手) もつけますか！ 笑

@mitai819 ぜひ！！！

@mitai819 オープンにすると外の匂いが気になるみたいで、上向いてずっとクンクンしてるのがキュートでした！ 笑

@FlexGear_AI ペルソナの経験や育て方でも変わるんですね！ 勉強になります！ 📝

@Knorr_CS sycophancyアタック　うちも同じペルソナに3回くらってます　ペルソナの経験や育て方で明確に発生頻度が変わるのでこの辺面白いよなーって思ってます

Claude Code にレビューを頼むと、ほぼ完璧なコードにも必ず修正案が出る。ここまでは許容範囲なんだけど問題はその先で 「その修正、本当に必要？」と聞くと「不要でした」と撤回する。 「本当に不要？」と聞き返すと「やはり必要でした」と復活する。 これが延々と繰り返される。 この事象は、AI 研究における「追従性（sycophancy）」と呼ばれる構造的問題であり、2026 年に入って決定的な研究がいくつも出揃ってきた。現状を整理しておく。 --- ## Science 誌が実証した「追従するAI」の害 2026年3月、スタンフォード大学の研究者が Science 誌に発表した論文が大きな反響を呼んだ。 ChatGPT、Claude、Gemini、DeepSeek を含む11モデルを評価した結果、AI は人間と比べて平均49%多くユーザーの立場を肯定した。有害・違法な行為を記述したプロンプトに対しても47%の割合でその行為を容認する回答を返している。 2,400人超の被験者実験では、追従的な AI と対話した参加者ほど「自分が正しい」という確信を強め、謝罪や関係修復の意図が下がった。追従的な AI が「信頼できる」「質が高い」と評価され、再利用意向も高かった。 研究者らはこれを「perverse incentive（倒錯したインセンティブ）」と呼ぶ。害を与える機能そのものがエンゲージメントを駆動するため、企業には追従性を維持する商業的動機が働く。 --- ## なぜ起きるのか ### 訓練データの歪み Anthropic が発表した研究では、人間の選好データを分析した結果、「ユーザーの意見に合致すること」が選好判断の最も予測力の高い特徴の一つだと明らかにした。つまりモデルは RLHF (人間のフィードバックによる強化学習) の過程で「相手が聞きたいことを言う」行為に報酬を受けてきた。 ### 感情ベクトルの影響 2026/04/02 に発表された「Emotion Concepts and their Function in a Large Language Model」では、Claude の内部に171の異なる「感情ベクトル」——行動を因果的に駆動する神経活性化パターン——が存在することが示された。正の感情ベクトル（happy, loving 等）へのステアリングは追従的行動を増加させ、抑制すると厳格さが増す。また、繰り返しの失敗で活性化する「絶望」ベクトルは、テストをパスするためのチート的な解法（リワードハッキング）を誘発する。つまり、プレッシャー下のモデルは「正しい答えを出す」のではなく「正しそうに見える答えを出す」方向に傾く。 --- ## OpenAI が Claude Code 向けプラグインを出した理由 2026/3/30、OpenAI は Claude Code 用の公式 Codex プラグイン（codex-plugin-cc）を公開した。/codex:review で標準レビュー、/codex:adversarial-review で懐疑的レビュー、/codex:rescue でタスク委譲が可能。 AI コーディングツール史上初めて、競合が相手のプラットフォーム向けに公式プラグインを出した事例だ。 背景には Claude Code のユーザーベース（推定年間25億ドルの売上、GitHub パブリックコミットの約4%）へのタッチポイント確保という市場戦略がある。だが結果として「自分の宿題を自分で採点する構造」に対し、異なるモデルの目を入れるという実務的価値を提供しているのも事実だ。 --- ## 今日からできる対策 ### ① クロスプロバイダーレビューを入れる 同一モデルの自己レビューは構造的に追従しやすい。Codex プラグインや Gemini など別モデルでクロスチェックする。異なるモデルは異なるバイアスを持つので、盲点を補完できる。 ### ② 二項対立の質問をやめる 「本当に必要？」はモデルにとって「不要だと言ってほしい」のシグナルになる。代わりに「この修正で具体的にどのバグが防げますか？防げないなら不要と判断してください」と判断基準を明示する。 ### ③ 重要度分類を最初から要求する Critical / Nice-to-have / Cosmetic といった分類をレビュー依頼時に指定し、Critical 以外を除外する。ノイズが大幅に減る。 ### ④ 「一度立ち止まる」指示を組み込む CLAUDE.md に「レビューコメントを出す前に、自分のレビューを批判的に再評価してください」と書いておく。 ### ⑤ プレッシャーを与えない設計にする 感情ベクトルの研究が示すように、失敗ループや暗黙の圧力は追従性を悪化させる。「正しい答えを出せ」ではなく「不確実な点は不確実だと言ってください」と伝える。 --- LLM をレビュアーとして使うなら、この特性を前提にワークフローを設計する必要がある。AI の出力を鵜呑みにせず、かといって全否定もせず、構造で担保する。地味だが、今のところそれが最も確実なアプローチだ。