自動化

自動化に関する記事、ガイド、チュートリアル。開発者や企業向けの実践的な情報をまとめています。

AIエージェント決済とエージェンティックコマースの実像

AIエージェント決済は、この一年ほどで4つの競合する仕様と2つの業界団体、そして膨大な報道を生み出しました。まだ生み出していないのは、大多数の事業者にとっての売上です。この騒がしさと数字の落差こそ理解に値する部分です。熱狂的な論調も冷笑的な論調も、どちらも金銭的な損失につながる形で間違っているからです。 本物のものが作られているのは確かです。Google、OpenAI、Stripe、Coinbase、Shopify、Visa、Mastercard のいずれもがこの領域で仕様か製品を出荷しており、そのうち2つの仕様は単一のベンダーではなく中立の団体の下に移りました。一部はすでに本番で動いています。ただし本番のトラフィックの大半は、買い...

Agentforce: Salesforce AIエージェントの実費用

Agentforceは従量課金です。この一点だけで、予算の立て方は変わります。Salesforceの購入担当者の多くは席数ライセンスの発想で商談に入り、エージェントはユーザーあたり月額いくらかと尋ね、自社の請求書とは何の関係もない数字を受け取ります。請求額はエージェントが何回アクションを実行したかで決まり、その回数はエージェントの設計品質とナレッジベースの出来で決まります。 この点でAgentforceは、企業向けソフトウェアの購入としては異質です。エージェント内部の設計判断が、そのまま請求明細の項目になります。一問一答で答えるエージェントは、五段階を踏むエージェントの五分の一しか費用がかかりませんが、自分がどちらを作ったのかはライ...

Salesforce 連携:API 制限と設計と実際の費用

Salesforce 連携がプロトコルで失敗することは、まずありません。認証は解決済みの問題ですし、レコードを 1 件登録するのも解決済みの問題です。プロジェクトを終わらせるのは、1 日あたりのリクエスト割り当てと、データモデルの形のほうです。しかもその両方は、たいてい本番稼働から三週間ほど経った頃、夜間ジョブがエラーを返しはじめ、なぜテストでは通っていたのか誰も説明できなくなった時点で発見されます。 パターンは予測できるほど一貫しています。開発者は Developer Edition 組織に対して実装し、すべて通り、顧客が検収します。そのコードがやがて出会うのは、マーケティング用コネクタと、データウェアハウスへの抽出処理...

本当に何かを変えるポストモーテム

ポストモーテムは、開くのは簡単で、役に立つものにするのは難しい会議です。会議が開かれ、ドキュメントが書かれ、アクションアイテムが四つ記録され、そして六か月後に同じ障害がふたたび起きます。そのころ誰かが、まったく別のものを探している最中に、あの古いドキュメントを見つけることになります。 この話題では「非難なし」という言葉にほとんどの注目が集まります。その原則は実際に重要なのですが、失敗が起きているのはそこではありません。非難なしを厳格に守りながら、それでも何ひとつ変わらないレビューを回している組織はいくらでもあります。理由は単純で、レビューそのものを成果物として扱ってしまい、成果物を生み出すための手段として扱わなかったからです。 あな...

小規模チームのソフトウェアサプライチェーン対策

ソフトウェアサプライチェーンのセキュリティは、専任のセキュリティ部門を持つ大きな組織の課題のように聞こえます。しかし、その捉え方こそが誤解のもとです。いくつかのサービスを運用しているだけの小さなチームでも、実際には誰も中身を読んだことのない数百のパッケージに依存しています。それらはビルドのたびに、自分たちが管理していないレジストリから取得され、デプロイ用の認証情報が置かれているマシンの上でインストールスクリプトを実行します。 危険にさらされる度合いは、会社の規模には比例しません。依存パッケージの数と、ビルドがどこまで自動化されているかに比例します。そして小さなチームほど、前者は多く抱えている一方で、後者に目を光らせる人は少ない、とい...

読まれる技術ドキュメント

技術ドキュメントは、いつも決まった、そして予測のつくかたちで失敗します。誰かが二週間ほどの落ち着いた時期に大量に書き上げ、そのあいだにシステムのほうが変わり、誰も更新せず、一年も経てば、その文書は自信たっぷりに間違ったことを述べている状態になります。そこから先は、何もないよりも悪い状態です。書いてあることを信じた読み手が、すでに成り立たなくなった情報にもとづいて手を動かしてしまうからです。 これに対するよくある反応は、もっと書こうという号令です。ところがそれは同じ失敗を早めるだけで終わります。役に立つ反応は、書く量を減らし、そのうえで何を書くのかを選ぶことです。ここでの制約は書く手間ではありません。書いたあとに保守し続ける手間のほう...

最初の一週間で成果を出す開発者オンボーディング

開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされるか、という点にあります。 追いかける価...

意味のある稼働率SLAとは

稼働率SLAは約束のように見えて、実際には返金規定のように振る舞います。提供側はそれを知っています。契約する側は知らないことが多く、可用性を買ったつもりでサービスレベル契約に署名しますが、実際に買っているのは、可用性が得られなかったときに受け取れるわずかな割引です。 それが必ずしも悪い取引だというわけではありません。ただ、多くの人が結んでいるつもりの取引とは別の取引であり、その違いはシステムが止まって、契約には何と書いてあるのかと誰かが尋ねた瞬間に効いてきます。 スリーナインは完璧に近く聞こえますが、月に43分の停止を許容します。 フォーナインが許容するのは4分です。平日の午後に43分の障害を吸収できる事業なら、99.9%で十分であ...

小規模ソフトウェアチームの災害復旧

小規模なチームにおける災害復旧は、たいていの場合、誰も開いたことのないドキュメントの中の一行で終わっています。バックアップは有効になっています、という一文です。その記述自体は事実ですが、何かの答えになっているわけではありません。実際に障害が起きたときに戻ってくるデータがどれだけ古いものなのか、復元にどれくらいの時間がかかるのか、そしてこれまでに誰か一人でも最後まで復元をやり切ったことがあるのか、そのどれについても何ひとつ語っていないからです。 バックアップを持っているという状態と、実際に復旧できるという状態のあいだには、はっきりとした隔たりがあります。ほとんどの障害が本格的なインシデントへ変わるのは、まさにその隔たりの中でのことで...

実際のユーザーに耐えるソフトウェアテスト戦略

ソフトウェアテスト戦略は、たいていカバレッジという数字で語られます。しかしカバレッジは、この分野全体のなかで最も情報量の少ない数字です。カバレッジ九十パーセントのコードベースであっても、最もよく使われる経路でバグを本番に送り出すことがあります。カバレッジが測っているのは、テスト実行中にどの行が実行されたかであって、その行について意味のある検証が行われたかどうかではないからです。 自分たちのテストスイートを信頼しているチームは、パーセンテージが最も高いチームではありません。本当に壊れているときにテストが落ち、それ以外のときは静かにしているチームです。そしてこの性質は、お金で買うのがはるかに難しいことが分かっています。 どんなテストにつ...