いとー @sofaito

2026年10月7日、Anthropicが小型のAIモデル「Claude Haiku 5.5」を公開しました。あわせて、上位モデルSonnet 5.5の一部料金の値下げと、Max・Teamプラン向けの毎月のAPIクレジット（自社の仕組みからAIを呼び出す分に使える利用枠）も発表しています。AIの費用を見積もるうえで、値下げと「数え方の変更」が同時に起きているのが今回の要点です。 公式に書かれている主な点 ・Haiku 5.5は、前のHaiku 4.5より平均でおよそ75%安く動かせる、と書かれています。内訳は、10万トークン（トークン＝AIが文章を数える単位）までの依頼で90%安く、10万トークンを超える依頼では50%安い。Haiku 4.5では、依頼の90%が10万トークンまでだったそうです ・100万トークンあたりの料金は、入力が0.10ドル（10万トークン超は0.50ドル）、出力が0.50ドル（同2.50ドル）。Haiku 4.5は入力1.00ドル、出力5.00ドルでした。依頼の長さで単価が2段階に分かれます ・数え方も変わります。Haiku 5.5は新しい数え方を使うため、同じ文章でもHaiku 4.5よりおよそ30%多いトークンとして数えられる、と開発者向けの移行ガイドにあります。増え方は文章の中身によって変わります。上の「およそ75%安く」は、この増加も計算に入れた数字です ・移行ガイドは、Haiku 4.5のトークン数をもとにした費用の見積もりは、Haiku 5.5の数え方と料金で計算し直すよう書いています ・Sonnet 5.5は、キャッシュ読み込み（くり返し送る同じ指示や資料を、2回目以降は安く読む仕組み）の料金が半分になり、100万トークンあたり0.20ドルから0.10ドルになりました。これで、AIに作業をまとめて任せる多くの使い方で、およそ20%安くなるとしています ・Teamプランには、今週から順次、毎月最大500ドル分のAPIクレジットが付きます。席数で決まり、チーム全体で共有します。ヘルプ記事によると、使わなかった分は翌月に繰り越さず、対話しながら使うClaude Codeには使えません 日本の会社にとって変わること ・単価は下がりますが、同じ文章でも数えられる量は増えます。これまでのトークン数に新しい単価を掛けるだけでは、費用を見誤るおそれがあります ・長い資料を丸ごと読ませる使い方（10万トークン超）は、値下げ幅が50%にとどまります。どんな長さの依頼が多いかで、実際の下がり方が変わります 経営者がまず確かめること：自社のAIの費用を、どのモデルで、どの数え方の前提で見積もっているか。 anthropic.com/claude-haiku-5…

肌感覚で言うと、日本の中小企業にはほとんどCTOがいません。CTOがいてシステム開発がちゃんとできれば、めっちゃ伸びるのに、と思う会社がほとんどです。だから、めちゃくちゃもったいない。 ■事実：米国では、CTOの基本給だけでもこの水準です 米国の人材紹介会社JRG Partnersの2026年の目安（directional＝だいたいの目安）では、次のとおりです。 ・売上2,500万ドル未満：基本給 20万〜27.5万ドル ・売上2,500万〜1億ドル：基本給 25万〜35万ドル 出典：JRG Partners「CTO Salary Guide 2026」（2026-07-07） 常勤のCTOを置く会社は、それだけ「技術の判断」に人件費を払っている、という目安です。 ■私の考え：もったいないのは、伸びしろがあるのに判断する人がいないことです 判断する人がいない会社で起きやすいことが、3つあります。 1. 外注の丸投げ 「何を作るか」を社内で決めきれないまま、開発会社に渡します。私は約3,000万円かけて外注し、現場で使えないものを作った当事者です。完成がゴールになり、「現場が本当に使えるか」が後回しになっていました。 2. 見積もりの良し悪しが分からない 判断できる人がいないと、届いた見積もりが妥当かどうかを社内で決められません。何を後回しにできるのかも、感覚のまま進みます。 3. 作っても使われない／AIを入れても定着しない 作ることだけが進むと、現場の運用と責任者が残ります。AIが試しの段階で止まるのは、定着の責任者がいないからだと私は考えています。 CTOがいてシステム開発がちゃんと回れば伸びる会社なのに、その判断が空いている。だからもったいない。 ■解決の目安：常勤CTOを雇う前に、まず「システムの顧問」で判断を買う 私は、常勤のCTOを雇う前に、まず「システムの顧問」として判断を買うのがよいと考えています。開発の外注とは違い、何をどう作るかの判断を引き受ける役割です。 社内で先に決めること（例） ・いま止まっている売上や業務はどれか（1点に絞る） ・今回作る範囲と、後回しにする範囲 ・誰が「妥当だ」と最終判断するか ・現場で使う責任者は誰か 外に任せること（例） ・見積もりの読み方と、比較の観点 ・作る／作らない／今は刷新しない、の選択肢の整理 ・入れる前に直す点（権限・監査・バックアップなど）の洗い出し 顧問は、役員の最終決定を奪いません。決める材料と、止め時の判断をそろえる役割です。 今日できること：いま進めているシステムやAIの案件を1つ選び、「この進め方で妥当だ」と誰が判断しているかを1行で書いてみてください。書けなければ、開発の外注より先に、判断する人を決めるところからです。

「AIで何でも作れる。あとは始めるだけ」という話を見かけます。作れるようになったのは本当です。ただ、作れることだけでは差がつかなくなりました。 ■事実：作れることは、コモディティ化しています 公開ブログ「AIファーストの罠」に書いたとおり、かつては特別だったスキルも、全員ができると差にならなくなります。スマホ、Excel、ブラインドタッチと同じで、「AIでものを作れること」も猛烈なスピードでありふれたものになっています。 同じブログで書いた外注の失敗も、構造は同じでした。約3,000万円かけてシステムを外注したとき、私も開発会社も、いつのまにか「完成させること」がゴールになり、「現場が本当に使えるか」が後回しになっていました。出来上がったものは現場で使われず、結局Excelに戻りました。 AIは、この順番の間違いもそのまま速くします。正しい順番なら加速装置になります。順番を間違えると、間違った方向に高速で進むだけになります。 ■私の考え：ツールの前に、「誰の、どの困りごとを解くか」を決める 私はこれを「ビジネスファースト・AIセカンド」と呼んでいます。困っている人の問題を先に設計し、その解決の手段としてAIを使う順番です。AIの能力が先で、あとから「さて何のビジネスをしようか」とくっつけようとするのが、AIファーストの落とし穴です。 価値は、「作れること」から次の2つへ移った、と私は感じています。 1. 何を、誰のために作るのかを決める部分 2. 使う人の課題理解と、作ったあとに運用・改善し続ける部分 ここはコピーしにくいです。画面や仕様の見た目は真似できても、「この会社の、この業務の、この人が、ここで詰まる」を理解した設計判断の積み重ねは、丸投げできません。 ■「誰の、どの困りごとを解くか」の決め方の目安 社内のAI・システム案件を進める前に、次を1行ずつ書けるかを見ます。 ・誰が困っているか（「DX」ではなく、毎日この作業で止まっている人まで落とす） ・どの困りごとか（止まっている一手。例：見積もりの転記、在庫の確認待ち） ・解けたら何が変わるか（時間、ミス、売上のうち、測れるもの1つ） ・今回は作らないこと（後回しにする範囲） ・誰が「妥当だ」と止める／進めるか 1行も書けない案件は、ツール選びより先に、順番が決まっていません。完成がゴールになっている合図です。 今日できること：社内で進んでいるAIやシステムの案件を1つ選び、「誰の、どの困りごとを解くか」を1行で書いてみてください。書けなければ、新しいツールを入れる前に、そこを決めるところからです。

2026年10月8日、JPCERT/CC（国内の情報セキュリティ事故について連絡や調整をしている機関）が「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」を出しました。2026年9月前後から、国内の組織で不正アクセスによる個人情報などの漏えいが続いていることを受けたものです。ふだんから起きているランサムウェア（データを暗号化して身代金を求める攻撃）とは別に、大量の漏えいにつながっている攻撃の型を取り上げています。 公式に書かれている主な点 ・攻撃は一つのソフトの弱点に絞ったものではなく、相手ごとに既知の脆弱性（セキュリティ上の弱点）を探して試すものがあります。弱点ではない管理の不備を突いて、設定ファイルやバックアップファイルを盗もうとする例もあります ・API（システム同士がデータをやり取りする窓口）に不正な要求を送り、利用者の権限を変える、不正なアカウントを作る、情報を書き換えるといった被害が報告されています。公開しているスマホアプリを解析して窓口や鍵を見つける手口や、別のシステムから盗んだAPIキーを使う手口もあります ・BIツール（社内のデータを集計して画面に出す道具）のひとつ、Metabaseの脆弱性（JPCERT/CCは8月14日に注意喚起済み）を悪用したものもあります ・一般向けのアプリだけでなく、BIツールや従業員向けの管理システムなど、外の不特定多数が使うことを想定していないシステムが被害に遭い、中に保存していた情報が漏れた例もあります ・対策として、APIへのアクセス回数の制限、窓口ごとのアクセス制御、APIキーやトークン（システムを使うための許可証）には必要最小限の権限と適切な有効期限をつけること、不要なものや漏えいが疑われるものはすぐ無効にできるようにすること、修正版の適用、業務に必要のない管理機能をインターネットに出さないこと、保存期間を過ぎたデータや使い終わったデータを残さないことなどを挙げています 日本の会社にとって変わること ・注意喚起は、従業員向けやBIツールのような社内向けのシステムも点検の対象だと、くり返し書いています。「社内の人しか使わない」は、点検を省く理由にならないということです ・漏えいが疑われるキーをすぐ止めるには、どのキーをどのシステムや取引先に、どんな権限で渡しているかが分かっている必要があります 経営者がまず確かめること：社内向けのシステム（集計画面や管理画面など）のうち、インターネットから入れるものがどれか、一覧になっているか。 jpcert.or.jp/at/2026/at2600…

システムの見積もりが予算に合わないとき、私は値引きではなく、作る範囲を減らして合わせます。 値引きしても、作る量は同じまま残ります。範囲を減らせば、何を後に回したのかが発注側にも見えます。 残すのは、いま止まっている売上や業務に効く1か所です。基幹刷新でも、いきなり全機能を作らず、段階的に移すのを基本にしています。 今日できること：手元の見積書から、今回の目的に直接効かない機能を1つ選び、それを次の段階に回した場合の金額を開発会社に聞いてみる。

AIを仕事で使う前に、私がまず決めるのは「どのデータをAIに渡してよいか」と「渡したデータが、どこに、どれだけ残るか」です。AIの性能より先に、ここを決めて書面にしておくと、あとで慌てずに済むと考えています。 ■事実：OpenAIが、データを残さない使い方の安全確認のしくみを広げ始めました OpenAIは2026年8月19日に「Offering Zero Data Retention for frontier models」を公開し、2026年9月22日の更新で、Private Safety Processing（中身を人が見ずに、自動で悪用の兆しを見つけるしくみ）を、API（自社のシステムからAIを呼び出す窓口）の利用者へ段階的に提供し始めたと発表しました。 openai.com/index/offering… 公式ページと開発者向けの資料に書かれていることを整理します。 ・Zero Data Retention（ゼロ・データ・リテンション：入力と回答を処理のあとに残さない取り決め）は、条件を満たすAPIの利用者向けで、OpenAIの事前の承認が必要です。 ・何も申し込まない場合、APIの利用では、悪用を見張るための記録（入力や回答を含むことがある）が、原則として最大30日残ると書かれています。 ・APIに送ったデータは、利用者が自分から共有を選ばない限り、モデルの学習に使わないと書かれています。 ・データを残さない場合でも、法律で報告が義務づけられている一部の画像は例外として残ると、注記されています。 ここから分かるのは、同じAIでも、使い方や契約によってデータの残り方が違うということです。 ■日本の会社にとって このページと資料に書かれているのは、自社のシステムからAPIでつなぐ使い方の話です。社員がふだん使うチャット画面のサービスは、ここでは扱われていません。「うちはAIにデータを残さない設定にしている」と思っていても、どのサービスを、どの契約で使っているかを確かめないと、実際の残り方は分かりません。 ■私の考え 私はシステムを作るとき、個人情報の置き場所を、作り始める前に決めて書面にします。どのデータをどこに、どれだけ置くか。あとから移すのは、たいてい大ごとになるからです。 AIも同じだと考えています。使い始めてから「このデータは渡してよかったのか」を考えるのでは遅いので、使い始める前に、渡してよいデータの範囲と、残り方を決めておきます。 経営者がまず決めること：自社のどのデータをAIに渡してよいかの線引きです。 今日できること：社内で使っているAIサービスを1つ選び、契約書か管理画面で、入力したデータが学習に使われるかどうかと、どれだけの期間残るかが書かれている場所を確かめてみてください。

Anthropicは2026年10月6日、Googleのドキュメント・スプレッドシート・スライドの中でClaudeを使える追加機能（アドオン）「Claude for Google Workspace」を、Claudeの有料プラン（Pro・Max・Team・Enterprise）でパブリックベータ（誰でも試せる先行版）として公開しました。あわせて、Claudeのチャット画面からGoogleのファイルを作ったり直したりできるコネクタ（外部のサービスとつなぐ機能）も、ベータで出ています。 公式に書かれている主な点 ・ファイルの横にClaudeの欄（サイドバー）が開き、開いているファイルと、選んだ文字・セル・スライドを読んで、そのファイルを直接書き換えます ・進め方は2つから選べます。初期設定の「Ask before edits」では、変更ごとに要約付きの承認カードが出て、こちらが許可するまで書き換えません。「Accept all edits」では、止まらずに書き換えを進めます ・「Accept all edits」でも、リンクや外部の画像、Webアドレス、ファイルへのアクセス権に関わる操作の前では止まって許可を求めます。ファイルの共有、他の人へのアクセス権の付与、持ち主の変更はできません ・Claudeの変更はGoogle上では使っている本人の名前で記録され、版の履歴（ファイルの変更履歴）から元に戻せます。一緒に編集している人からは本人の編集として見え、Claudeとの会話は見えません ・このアドオンが読めるのは、開いたその1つのファイルだけです。ただし、Googleドライブのコネクタを別につないでいると、ほかのファイルも参照できます（初期設定はオフ） ・送った内容はモデルの学習に使わないとされています。入力と出力は原則30日以内に削除され、会社で決めたデータ保持の設定は引き継がれません。データを保存しない契約（ゼロデータ保持）には対応していません ・社外から受け取ったファイルには、他人が書いた指示（白い文字や小さな文字など）が隠れていることがあるとして、承認の前に提案内容を確かめるよう案内しています ・Enterpriseプランでは、やり取りと変更内容を取り出す仕組み（Compliance API）、自社で管理する暗号鍵（CMEK）、監査記録の書き出し（OpenTelemetry）がこのアドオンにも使えます 誰が入れられるか ・社員が自分でGoogle Workspace Marketplace（Googleのアプリ追加の場所）から入れる方法と、Google Workspaceの特権管理者（最上位の管理者）が会社全体や特定のグループに一括で入れる方法があります ・どちらが使えるかは、Claudeのプランではなく、Google側のMarketplaceの設定で決まります ・チャット画面からGoogleのファイルを直すコネクタは、TeamとEnterpriseプランでは、先にClaudeの組織のオーナーが有効にする必要があります 日本の会社にとって変わること ・Google Workspaceを使っている会社では、Marketplaceの設定しだいで、社員が管理者を通さずに会社のファイルの中でClaudeを使い始められます ・データの扱いはプランで変わります。Team・Enterpriseは会社向けの利用規約とデータ処理の取り決め、Pro・Maxは個人向けの利用規約とプライバシーポリシーが適用されます ・公式ページには、国・地域ごとの条件や追加料金の記載はありません 経営者がまず確かめること：自社のGoogle Workspaceで、社員がMarketplaceのアプリを自分で入れられる設定になっているか。 claude.com/resources/arti… support.claude.com/en/articles/16…

予約・顧客管理・集客が手作業で、店舗ごとに運用がばらついている。整体・治療院向けの予約システムは、この課題から始まった事例です。iiwayo.techで公開している導入事例CASE_03です。 支援したのは、予約・顧客管理の一元化と、店舗ごとの集客と運用です。システムは予約・顧客管理・ブログ生成・症状ページ・SEO/AIO対策です。 手作業のままだと、店舗が増えるほど、やり方も店舗の数だけ増えていきます。

「パスワード管理ツールを入れているから、偽サイトにはだまされない」とは、私は考えていません。パスワード管理ツール（IDとパスワードを保存して、自動で入力してくれる道具）は、偽サイトに気づくための手がかりにはなります。でも、守りの本体は別のところにあります。 偽サイトの見た目やURLが本物に近いほど、人の目でも道具でも見抜きにくくなります。だからこそ、「見抜けなかったときにどうなるか」を先に考えておきたいところです。 ■事実：公的な指針でも「ID・パスワードだけでは足りない」とされています フィッシング対策協議会（フィッシング詐欺の対策に取り組む国内の団体）の「利用者向けフィッシング詐欺対策ガイドライン 2026年度版」には、次のように書かれています。 ・いつもはパスワードマネージャーなどで自動的にログインできるのにできないときは、偽サイトの可能性がある。つまり、自動入力は「おかしい」と気づくための合図です。 ・IDとパスワードの認証だけでは、フィッシング対策として十分とは言えない。 ・多要素認証（パスワードのほかに、スマホへの通知や確認コードなど別の手段も使って本人を確かめるしくみ）は、攻撃者による不正ログインを防ぐのに有効。 ・2026年度版では、守ってほしい基本行動として「技術で守る（多要素認証、パスキーなどをオンにする）」「入力する前にひと呼吸（メールやSMSのリンク先では入力せず、ブックマークや公式アプリから開く）」「迷ったら相談」の3つが示されています。 Googleのヘルプにも、パスキー（パスワードの代わりに、スマホの指紋・顔認証や画面ロックでログインするしくみ）は、パスワードと違って共有したりコピーしたり書き留めたりできず、フィッシングへの守りを強められると書かれています。 ■私の考え 私は、社外から社内のデータにつなぐしくみを選ぶとき、製品名より条件を見ます。多要素認証を使えるか。退職者や、なくした端末をすぐ無効にできるか。利用者ごとにつなげる範囲を分けられるか。接続の記録を残せるか。 パスワード管理ツールも同じで、「入れたかどうか」より「パスワードが盗まれたときに何が起きるか」で考えます。パスワードが盗まれても多要素認証やパスキーで入れない。入られても、すぐ止められる。ここまでそろって、はじめて守りになると考えています。 今日できること：社長ご自身と、経理や管理者のアカウントで、多要素認証かパスキーがオンになっているかを確かめてみてください。

2026年10月7日、個人情報保護委員会が「大規模な漏えい等事案を踏まえた対応について（注意喚起）」を公表しました。同じ日に、漏えい事例をまとめた資料「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」の改訂版も出ています。外からの不正アクセスで大量の個人データが漏えいした事案を受けたものです。 公式に書かれている主な点 ・とくに呼びかけている相手は、大量の個人情報を持つ事業者や、知られると本人への影響が大きい情報、お金の被害や詐欺につながるおそれのある個人情報を持つ事業者です ・ガイドラインにある安全管理措置（個人データを守るために会社が取る対策）の「手法の例示」は、来年4月に見直しを確定する予定です。今回はその中身を先取りして示しています ・先取りで示された例：管理者権限を使う人・端末・場面を最小限にする。異動や退職のときにアクセス権を変え、定期的に棚卸しする。社外からのアクセスや管理者権限には、多要素認証（パスワードに加えて別の手段でも本人を確かめるしくみ。フィッシングに強いものを含む）を使う。ログ（操作や接続の記録）を一定期間保管して定期的に分析する。侵入されたら、そのシステムを止めたり切り離したり、アカウントを無効にしたりする ・中小規模事業者向けの例示も並んでいます（OSを最新に保つ、セキュリティ対策ソフトを自動更新で最新にする、ログを一定期間保管する など） ・使う必要がなくなった個人データは遅滞なく消すよう努める、という法律の定めを改めて注意喚起しています。消していなかったために被害が深刻になった事例にも触れています ・WARNINGは漏えいの事例を9つに分けています。1つ目は「脆弱性（セキュリティ上の弱点）の放置」で、原因として、システム業者とは導入の契約しか結んでおらず脆弱性対応を含む保守契約がなかった、保守契約はあったが脆弱性対応が含まれていなかった、などを挙げています ・ほかに、グループ会社への監督不足、クラウドサービスからの漏えい、API（システム同士をつなぐ窓口）の悪用などの事例があります ・対策はどれか一つで足りるものではなく多層的に取ること、経営層も交えて組織として対応することが必要だと書かれています 日本の会社にとって変わること ・ガイドラインでは、「講じなければならない措置」に従わないと法律違反と判断される可能性がある一方、「手法の例示」は全部そろえなくても直ちに違反になるわけではない、と整理されています。今回、来年4月の見直しの中身が先に示されたことで、何を目安に整えるかが具体的になりました ・システムを外に頼んでいる会社では、保守契約に脆弱性への対応が入っていないことが、漏えいの原因の例として委員会の資料に明記されました 経営者がまず確かめること：自社のシステムの保守契約に脆弱性への対応が入っているか。使い終わった顧客データを消す決まりがあるか。 ppc.go.jp/news/careful_i…

「AIに確かめさせたから大丈夫」は、私は確認だと考えていません。AIの答えを同じAIにもう一度聞いても、それっぽい答えがもう一度出てくるだけのことがあるからです。確かめるときは、元の資料か、別の方法と突き合わせます。 AIに下書きを作らせ、そのままAIに見直させて仕上げる使い方は、速くて便利です。ただ、「AIが見直したから正しい」と思い込むと、間違いがそのまま社外に出ていきます。 ■事実：AIを作っている会社も「AIは間違える」と書いています Anthropicの公式ドキュメントには、ハルシネーション（AIが事実と違う内容を、もっともらしく作ってしまうこと）を減らすための方法がまとめられています。 ・最先端のAIでも、事実と違う文章や、渡した資料と食い違う文章を作ることがあると書かれています。 ・減らす方法として、「分からないときは分からないと言わせる」「長い資料では、先に資料から一字一句そのままの引用を抜き出させ、それをもとに答えさせる」「答えの一つ一つに引用と出典を付けさせ、裏付けの引用が見つからない主張は取り下げさせる」が挙げられています。 ・同じ質問を何回か聞いて答えを比べ、食い違いがあればハルシネーションの可能性がある、という方法も載っています。 ここで大事なのは、確かめる方法の中心が「元の資料」に置かれていることです。答えを何回か比べる方法も、食い違いを見つける手がかりとして書かれています。 ■私の考え 私は、お金の計算をAIに任せきりにしません。AIが書いた計算とは別に、もう一度別の方法で計算して突き合わせ、一致しなければ止めます。計算式が正しく見えることと、正しいことは違うからです。 AIに確かめさせるときも同じです。同じAIに聞き直して答えがそろっても、正しいかどうかは分かりません。確かめる先は、AIの外にある元の資料か、別の方法です。 今日できること：社内でAIに作らせている資料を1つ選び、その中身を誰が、AIの外にある何と突き合わせて確かめているかを聞いてみてください。

AIに仕事を任せるとき、私がまず決めるのは「どこで人が承認するか」です。削除・上書き・一括変更・外部送信のように取り返しのつかない操作は、AIが提案し、人が承認してから実行する。この順番を先に決めておけば、AIに任せる範囲を安心して広げられると考えています。 最近は、AIが文章を書くだけでなく、ファイルを直したり、データを更新したり、メールを送ったりと、実際の「操作」まで行えるようになってきました。こうしたAIを、AIエージェント（指示を受けて、自分で手順を考えてツールを動かすAI）と呼びます。便利な反面、AIが間違えたときの影響は、文章の誤字とは比べものになりません。 ■事実：AIを作っている会社の公式資料にも「承認」のしくみがあります 開発者向けの公式資料を読むと、主要なAI各社は「AIの操作の前に人が承認する」しくみを用意しています。 ・Anthropicの公式ドキュメント：AIに許す操作を「許可する（allow）」「毎回確認する（ask）」「禁止する（deny）」の3つのルールで決められます。シェルのコマンド（パソコンへの直接の命令）は、読み取りだけの一部の命令を除いて、承認が必要とされています。 ・OpenAIの公式ドキュメント：ヒューマン・イン・ザ・ループ（途中に人の確認を入れるしくみ）として、影響の大きいツール呼び出し（AIが外部の機能を使うこと）を、人が承認か却下をするまで止めておく流れが説明されています。一方で、パソコンへの命令やファイル編集のツールでは、承認は「設定したときだけ有効」で、初期設定では入っていないとも書かれています。 ・Googleの公式ドキュメント：ツールの実行を一時停止して、人やほかのシステムに確認を求める機能があります。ただし、この機能は試験的な扱いと書かれています。 ここから分かるのは、承認のしくみは「用意されている」けれど、「どの操作に承認をかけるか」は使う側が決めることだという点です。 ■私の考え AIが間違えても、お客様は「AIが言ったなら仕方ない」とは受け取りません。「あなたの会社が言った」と受け取ります。だから私は、AIを裏で働かせても、最終承認の責任は人が持つ形にしています。 流れはシンプルです。 ①AIが提案する（何を、どこに、どれだけ変えるか） ②人が中身を見て承認する ③実行して、記録を残す 承認を挟むのは、あとから戻せないか、戻すのに手間がかかる操作です。 ・削除：消したデータやファイル ・上書き：前の内容が残らない書き換え ・一括変更：たくさんのデータを一度に変えること ・外部送信：メールの送信や、社外へのデータの受け渡し 逆に、すべての操作に承認をかけることはしません。何にでも承認を求めると、中身を読まずに承認を押すだけになりやすいからです。 AIは速く動けます。だからこそ、止める場所を人が先に決めておくことで、AIを安心して使える範囲が広がると、私は考えています。 今日できること：自社でAIに任せている（または任せようとしている）作業から、削除・上書き・一括変更・外部送信にあたるものを1つ選び、実行の前に誰が承認するかが決まっているか確かめてみてください。

2026年10月7日、IPA（情報処理推進機構）と、IPAとJPCERT/CCが運営する脆弱性情報サイトJVNが、シックス・アパート社のWebサイト管理システム「Movable Type」に複数の脆弱性（セキュリティ上の弱点）があると公表しました。同じ日に、開発元から修正版も出ています。会社のホームページやお知らせのページをMovable Typeで動かしている会社が対象です。 公式に書かれている主な点 ・いちばん深刻なのは、アップグレード用のプログラム（mt-upgrade.cgi）の弱点です。悪用されると、外からサーバー上で任意のプログラムを動かされるおそれがあり、IPAの評価は「緊急」（CVSS v3で9.4。CVSSは深刻さを10点満点で表す共通の物差し）です ・サイト内検索（mt-search.cgi）の弱点では、外から不正なデータベース操作をされ、非公開のデータを含む情報が出てしまうおそれがあります（「重要」、8.6） ・対象は Movable Type 9.2.1以前（クラウド版）、9.0.9以前、8.8.5以前、8.0.12以前と、Movable Type Premium 9.2.1以前（クラウド版）、9.0.9以前、2.17以前です ・サポートが終わった古い版（8.4系、7系以前、Premium 1系）も影響を受けます。開発元は4系から8.4系までを具体的に挙げています ・修正版は Movable Type 9.3.0／9.0.10／8.8.6／8.0.13、Premium 9.3.0／9.0.10／2.18 です ・すぐに更新できない場合の緩和策として、mt-upgrade.cgi・mt-search.cgi・mt-ftsearch.cgi を削除するか、外から実行できないようにする方法が示されています ・クラウド版は自動アップデートが初期設定で有効です。意図的に無効にしている場合は、早めの更新を求めています 日本の会社にとって変わること ・公式の案内で自動アップデートに触れているのはクラウド版だけです。自社や制作会社のサーバーに入れている版は、誰かが手で更新するか、緩和策を入れることになります ・サポートが終わった版には修正版がないため、新しい版への移行か緩和策のどちらかになります。開発元は、古い版を使っている会社にも内容の確認を求めています 経営者がまず確かめること：自社のホームページがMovable Typeで動いているか。動いているなら、版の番号と、更新する担当（社内か制作会社か）が決まっているか。 ipa.go.jp/security/secur… sixapart.jp/movabletype/ne…

公開している導入事例のひとつに、業務用美容機器メーカーがあります。課題は、代理店・導入サロン管理、問い合わせ導線、顧客対応が分散していた、とサイトに書いてあります。 作ったのは、代理店管理・導入サロン管理・LP・問い合わせ導線の整備です。 私がここで見るのは、機能の一覧より、販売と顧客対応がどこで別管理になっているかです。

AIが試すだけで止まるのは、定着の責任者がいないからだと私は考えています。その人は、社内で育てます。 TechTargetジャパンの記事では、米国の大手保険企業グループLiberty Mutual Groupが3000人の開発者にGitHub Copilotを展開したものの、利用範囲は基本的な機能にとどまった例が紹介されています。理由として挙げられているのは、組織で効果的に扱うための知見の不足です。 ライセンスは配れても、使いこなす知見は配れません。社内でためて広げる人が要ります。 経営者が最初に決めることは3つです。 ・会社として使うAIと、使ってよい業務を決める（社員がそれぞれ勝手に使う状態にはしない） ・定着の責任者を社内から1人指名する ・その人が社内に広げる時間を、業務として割り当てる 全社への配布は、その後です。

Googleが「Gemini 4 Argon」を発表しました（日本語版の公式ブログは10月1日付）。今はFairwind Programを通じて、サイバーセキュリティの担当者に順次展開している段階です。一般の企業が使える日付は書かれていません。 OpenAIのGPT-6.1 Sol、GPT-6 Astra、AnthropicのClaude Opus 5.5、Claude Fable 5.1と、公式ページの記載だけで並べてみました（表は画像に）。 見えたのは、性能の順位より、使える人と管理の仕組みの違いです。ChatGPT EnterpriseでAstraを使うには、管理者がワークスペースで有効にします（最初はオフ）。OpenAIもAnthropicも法人向けのデータは既定で学習に使わないとしていて、Enterpriseでは監査ログを取れます。Argonには、企業向け管理の記載がまだありません。 私は、社員がそれぞれ勝手にAIを選んで使う状態には反対です。会社として使うAIと使い方を決め、管理者が有効にするものを選び、ログが残る形で使う。新しいモデルが出ても、私はまずそこを見ます。

基幹システム刷新で、いきなり開発に入るとほぼ必ず失敗する、と私は見ています。 IIWAYO.TECHの基幹刷新の説明にも書いていますが、調査フェーズで「いまは刷新しない」「先に部分改修で対応する」という判断になることも珍しくありません。 私が先に見るのは、全機能の仕様より、現行業務の主要導線と例外処理がどこまで見えているかです。

Microsoft 365 Copilot Businessを販売パートナー経由（CSP）で新しく買うと、2026年12月1日から従量課金が最初からオンになります。初期の上限は1ユーザーあたり月4,000 Copilot Creditsで、管理者が変えられます。 Microsoftが販売パートナー向けに出しているPartner Centerの公式発表（2026年10月1日付）によると、12月1日から、CSP（Microsoftのライセンスを販売パートナー経由で買う仕組み）で購入する新しいMicrosoft 365 Copilot Businessのライセンスは、従量課金（使った分に応じて請求される課金）が初期設定で有効になります。開始日は、以前の案内の11月2日から12月1日に変わりました。 公式に書かれている主な点です。 ・対象：Microsoft 365 Copilot Businessの新規購入。単体の商品とセット商品（バンドル）の両方 ・初期の上限：1ユーザーあたり月4,000 Copilot Credits（Copilotの従量課金で使った量を数える単位）。管理者が調整できます ・公式の例：100ユーザーなら、初期の上限のままで月最大40万Copilot Creditsまで使え、請求は実際に使った分に基づきます ・従量課金で使える機能の例：Copilot Cowork、Work IQ APIs、GitHub Copilot Harness ・新しいライセンスには、従量課金に必要なAzureサブスクリプションの設定が含まれます ・提供：対象の市場から順に始まります。当初は、オーストラリア、ベルギー、ブラジル、フランス、ドイツ、インド、イタリア、韓国、オランダ、ポーランド、スペインでは提供されません ・パートナー向けの検証環境（Partner Centerのサンドボックス）は11月2日から使えます 日本の会社にとって変わること ・12月1日以降にCSP（販売パートナー経由）でCopilot Businessを新しく買うと、従量課金がオンの状態で始まります ・上限の初期値は1ユーザーあたり月4,000 Copilot Creditsで、管理者が調整できます ・当初は提供しない国の一覧に、日本は入っていません ・公式ページには、従量課金をオフにする方法、すでに使っているライセンスの扱い、1クレジットあたりの価格は書かれていません 経営者がまず確かめること：12月1日以降にCSP経由でCopilot Businessを新しく買う予定があるか。あるなら、上限を誰がいくつに設定するか。 learn.microsoft.com/en-us/partner-…

公開している導入事例のひとつに、製造業・専門商材のリユース企業があります。課題は、販売管理・在庫管理・見積・買取管理が分断し、業務が属人化していた、とサイトに書いてあります。 作ったのは、販売・在庫・見積・買取を一体化した業務システムです。 私がここで見るのは、機能の多さより、業務がどこで別管理になっているかです。

OpenAIが9月30日付で、米国の中小企業支援ネットワーク「America's SBDC」との提携を発表しました。私が目を留めたのは、中心がツールではなく、地域で相談に乗る人を育てることにある点です。 発表にある事実は次のとおりです。 ・最初の段階で、SBDCの相談員 約150人を研修する計画 ・対面の研修で、少なくとも1,000社に届けるのが目標 ・ワークショップは3時間の実習形式で、終了後も相談員がフォローする ・同時に出たレポートでは、9月の1週間に、従業員500人未満の企業の約400万人がOpenAIの製品を使った 自社に置き換えるなら、私が最初に確かめたいのは、AIの相談を社内で受ける人が決まっているかどうかです。