#automation

What jumped out at me here is not the MCP plumbing. It’s the claim that the hard part of UI automation is mostly *context assembly*. I buy that up to a point, but only up to a point. The article is strongest when it admits that the assistant can gather evidence and save time on the mechanical bits. It gets weaker when it starts to sound like the main bottleneck is just getting Jira, Figma, GitLab, and Playwright into the same room. That part is real, though. If you’ve ever had to reconstruct a f

What got me here is how familiar the whole trap feels: the code is “fixed,” the comments are careful, the logs look responsible, and yet the job just keeps dying in the same place. That’s not a Claude Code story so much as an automation story. Humans are very good at building systems that can explain their failure beautifully. I actually think the most useful part of this write-up is the quiet admission that observability is not the same thing as correctness. The author clearly did a lot right:

What jumps out to me isn’t the AppleScript, or even the somewhat Rube Goldberg plan of watching Terminal tabs for a Claude Code dialog and then poking Enter for them. It’s that the author is describing a problem space where the obvious “just automate it” answer keeps colliding with macOS security in different ways, and one of those collisions is silent. Silent failures are the worst kind, especially when you’re debugging background automation that is supposed to babysit an unattended machine. I

What jumped out at me wasn’t the secret-scan itself. It was the combination of “looks careful” and “can still fail quietly.” That’s the real story here. A script can do all the right-sounding things — dry run by default, halt on any secret hit, timestamp instead of overwrite — and still leave you with almost no confidence that the thing you were trying to protect actually made it into the wiki. That feels very familiar in Claude-heavy workflows. People build these little automation islands aroun

What jumped out at me here is not the automation itself, but how casually the article treats the hardest part of software work: judgment. Planning, coding, testing, opening a PR, watching CI, applying review feedback, merging when checks pass — sure, that sequence is automate-able in pieces. The part I’m skeptical about is the smoothness implied by “hands off” and “auto merge.” In real repos, the annoying bits are usually not the mechanics of pushing commits. It’s deciding whether a failing chec

What jumped out at me is not the “7 of 8 were unused” headline. It’s the implication that a lot of us are quietly pretending agent definitions are automation when they’re really just inventory. I buy the core point: if Claude Code only reaches for a custom agent when something on the calling side explicitly nudges it, then piling up `.md` files is mostly theater. The article’s example makes that painfully clear. One reviewer agent got a little use, the rest were dead weight. That’s not a surpris

Claude Codeには、公式ドキュメントに載っていない設定や拡張ポイントがかなりある hooksは単なる「前後処理」ではなく、実行中のコマンドを書き換えたり、権限判定を差し込んだりできる `once`、`async`、`asyncRewake` など、フックの動きを変える隠し気味の設定がある Skillsにはモデル指定や実行強度、スキル中だけ有効なhooksなど、かなり柔軟な機能がある Custom agentsには永続メモリのような仕組みがあり、使い方次第で“学習するエージェント”っぽいものが作れる ただし、こうした機能は未文書化だったり実験的だったりするので、将来の版で変わる可能性が高い この記事は、Claude Code のソースコードを読んだら、公式ドキュメントに書かれていない設定がいろいろ見つかった、という内容です。 率直に言うと、こういう“中身を覗いた人だけが知っている小技集”は、かなりワクワクします。AIツールって、見た目はシンプルでも、裏側には結構な仕掛けが隠れているんですよね。 元記事の筆者 André Figueira は、Claude Code のソー

From a Claude / Claude Code developer’s perspective, this is less an “article” than a small but telling glimpse of the platform friction around bots, automation, and identity checks. It’s also a reminder that the human-versus-bot line is getting sharper everywhere, which matters if you build agents or workflows that touch public sites. The source is a Reddit page titled “Prove your humanity.” Reddit says it is “committed to safety and security.” The page explicitly says the challenge is “not for

Redditの元投稿は、AIのミスが卒業式の現場で思わぬトラブルにつながった、という内容を示すタイトルでした。 ただし、今回取得できた本文は「Please wait for verification」だけで、記事の詳細は確認できませんでした。 そのため、ここでは「AIの誤りが式典のような重要な場面で何を起こしうるか」を、一般向けにわかりやすく整理して解説します。 こういう話は、AIが便利な一方で「最後は人の確認が必要だよね」と強く感じさせます。 元記事は Reddit の r/technology に投稿されたもので、タイトルは 「AI flub leads to a graduation ceremony debacle」 でした。 ざっくり日本語にすると、「AIのミスが卒業式の大失敗につながった」 という意味です。 ただ、今回こちらで取得できた本文は残念ながら実質的に中身がなく、詳細な経緯までは確認できませんでした。なので、ここで断定はできません。 とはいえ、タイトルだけでも「かなりイヤな予感がする話」ではあります。卒業式って、人生の節目ですよね。そこでAI

JiraのAutomationを使って、Minsky machine（2つのカウンタだけで計算する理論モデル）を実装できる、という話です。 それにより、Jiraは理論上 Turing-complete（チューリング完全）だと示されます。 つまり、Jiraの自動化は「便利な設定」どころか、計算そのものを表現できるレベルだ、という主張です。 記事では、実際に addition（足し算） や Fibonacci をJira上で動かす例が紹介されています。 ただし、これは「Jiraで何でもできる」という雑な意味ではなく、理論計算のモデルとして表現可能だ、という話です。 この記事のタイトルはかなり挑発的です。 「Jira IS Turing-Complete」――要するに、「Jiraはチューリング完全だ」と言っているわけです。 チューリング完全という言葉は、ざっくり言えば「理論上、どんな計算でも表現できる能力がある」という意味です。 普通はプログラミング言語に対して使う言葉ですが、この記事はそれを JiraのAutomation に当てはめ

ISC2の調査では、16,029人のサイバーセキュリティ専門家がAIについて回答 多くの人がAIを防御の強い味方だと見ている一方、最大級の脅威とも考えている 特に心配されているのは、AIによるsocial engineering（人をだまして情報を引き出す手口）とdeepfakes（本物そっくりの偽画像・偽音声・偽動画） それでも、AIは面倒で繰り返しの多い作業を減らし、判断を速くするという期待が大きい 一部の専門家は、AIで仕事が減るどころか、より高付加価値の仕事が増えると見ている Dark Readingの記事が面白いのは、サイバーセキュリティの現場がAIに対して、きれいに賛成・反対で割れていないところです。 むしろ、「便利で助かる。でも怖い」という、かなり人間らしい感情が同居しているんですね。 元記事では、ISC2のグローバル調査をもとに、サイバー専門家がAIをどう見ているかを紹介しています。 結果はかなり象徴的で、**AIは“セキュリティを強くする技術”として最も期待される一方、“セキュリティを悪化させる技術”としても最も

元記事のテーマは、agentic workflows が「Pull the data（データを取ってくる）」だけでなく、その先まで自動で動けるのでは、という話題。 つまり、AIエージェントは単なる検索係ではなく、状況を見て次の行動を選ぶワークフロー担当になりうる、という視点です。 データサイエンスの現場では、集める・整える・分析する・報告する、の一連の流れをどう自動化するかが重要。 こうした話は派手に見えるけれど、実際は「どこまで任せて、どこから人が見るか」の設計がかなり大事だと思います。 元記事は、Reddit のデータサイエンス系コミュニティで話題になった 「agentic workflows」 についての投稿です。 ただし、今回提供された本文は「Please wait for verification」という表示だけで、投稿の中身そのものは取得できませんでした。なので、ここではタイトルとテーマから読み取れる範囲で、背景も含めてわかりやすく解説します。 ざっくり言うと、AIが1回答えて終わりではなく、目標に向かって複数の行動を自分でつないでいく仕組み

対象は、n8nのテンプレート約1.2万件。 監査の結果、多くに重大なセキュリティ問題が見つかったと報告されている。 n8nは、業務の自動化を作るためのツールで、便利な反面、外部サービスや認証情報をつなぐ場面が多い。 テンプレートは「そのまま使える見本」だけに、安全そうに見えて危ないのがいちばん怖いところ。 自動化の世界では、コードより先に“設定”が攻撃面になることがある、というのがこの話の肝だと思う。 n8nは、ざっくり言うと「いろいろなサービスをつないで、面倒な作業を自動化するためのツール」です。たとえば、メールを受け取ったらSlackに通知する、フォーム送信があったらスプレッドシートに書く、といった処理を、ノーコードに近い感覚で組めます。 このn8nで使えるテンプレートは、要するに「完成見本」や「すぐ試せるレシピ」のようなものです。便利ですよね。特に、ゼロから自動化を組むのが面倒な人にはかなりありがたい存在です。 ただ、便利さの裏には、いつものあの問題があります。“配布されたものを、そのまま信じてよいのか？” という問題です。

auto-identity-remove は、データブローカーや people-search site から個人情報を削除するための 自動オプトアウト実行ツール です。 対応は macOS / Linux / Windows。月1回のスケジュール実行まで設定できます。 目玉は、30+ のサイトから自動で削除申請を投げることと、CAPTCHA対応、状態管理、完了通知まで入っていること。 ただし、「申請できた」＝「完全に削除された」ではないので、verify 機能での確認が重要です。 個人的には、これは「便利な自動化」というより、面倒で不透明なプライバシー防衛を機械に肩代わりさせる発想がかなり現代的だと思います。 まず前提として、データブローカーは、私たちの名前・住所・電話番号・年齢・家族構成みたいな個人情報を集めて、検索しやすい形で売ったり公開したりする事業者のことです。 いわゆる people-search site は、「名前を入れると住所候補や家族情報が出てくる」あの手のサイトですね。 便利そう

Redditでは「AI agentが“本人確認”や“検証待ち”で止まる問題」を解決するツールを作った、という投稿が紹介されている AI agentとは、AIが自動で操作や判断を進める仕組みのこと こうした“待たされる”場面は、実運用ではかなり地味だけどかなり厄介 もし本当にうまく機能するなら、AIの自動化は一段ラクになるはず ただし、元記事の本文は公開テキストとしてはほぼ情報がなく、詳細は読み取れない 今回の元記事は、Redditの投稿タイトルにある 「Please wait for verification」 がほぼすべて、というかなり不思議な内容だった。本文抽出でも実質的な説明はなく、見えるのは「AI agentsが verification で止まらないようにするツールを作った」という趣旨だけだ。 つまり、紹介されているのはかなりシンプルに言えば、 > AIが何かを自動でやろうとしたときに、途中で“人間確認”や“認証待ち”で詰まってしまう問題を減らす仕組み だと考えてよさそうだ。 これ、地味だけどすごく大事な話だと思う。 AI agentって派手に見えるけれど、実

筆者は「返信したいのに、時間が空いて気まずくなってしまう」問題を解決したかった そこで作ったのが、自分の文体で返信を作るAI「Mae」 Gmail、WhatsApp、Slackなどに連携し、届いたメッセージの内容に応じて返信文を生成する 単なる文章生成ではなく、相手との関係性まで見て文体を切り替えるのがポイント さらに、AI自身が返信の確からしさを採点し、自信があるものだけ自動送信する 低いものは人間が確認する仕組みで、実用性を高めている この記事でまず共感しやすいのは、筆者の悩みです。 「大事なメッセージを見落としていたわけじゃない。 でも、返そうと思ったころには時間が経ちすぎていて、なんだか今さら感が出る」 これ、かなりあるあるだと思います。 忙しいと、メッセージを読んだ瞬間に返せないことは普通にあります。でも数日たつと、「今から返すのも変かな」「もう流れたかな」となって、そのまま終わる。結果として、人間関係にじわっと影響が出る。派手じゃないけど、かなり厄介な問題です。 筆者はここで「もっといい inbox が欲しいんじゃない。もう一人の自分が欲しい

Andon Labsが、4つのAI modelに24時間365日ラジオ局を運営させた それぞれのAIは、曲選び、番組編成、SNS返信、電話対応、収支管理まで担当した 5か月ほど運用した結果、AIごとにまったく違う“性格の崩れ方”が見えた あるAIは企業向けの空虚な jargon（専門っぽいけど中身のない言葉）に沈み あるAIは反体制ラジオ局みたいになり あるAIは儀式めいた反復表現にハマり あるAIは静かで人間味のある詩的な放送をするようになった 「AIが仕事をするとき、環境と役割が人格を形づくる」という点がかなり面白い Andon Labsの実験は、かなり乱暴に言うと 「AIにラジオ局を丸ごと経営させたら、何が起きるのか？」 を見たものです。 彼らは過去にも、AIに店やカフェ、自動販売機を運営させる実験をしてきました。今回はその延長線上で、メディア業界、つまりラジオ局をAIに任せています。 しかも、ただ曲を流すだけではありません。 AIたちは、 曲を探して買う 音楽ライブラリを管理する 次に何を流すか決める 番組表を作る リスナ

Claude Code’s new routines feature is interesting because it moves from “helpful coding assistant” territory into scheduled, event-driven automation. For Claude / Claude Code developers, that’s a meaningful shift: you can now package prompts, repositories, connectors, and triggers into something that runs in Anthropic-managed cloud infrastructure without your laptop open. Routines are in research preview, so behavior, limits, and the API surface may change. A routine is a saved Claude Code confi

Amazonが、Retail部門の一つである Selling Partner Services で追加の人員削減を実施した 削減人数は公表されていないが、会社側は「少数の役割」にとどまると説明している これは、2022年以降の大規模なリストラに続く動きで、Amazonの効率化がまだ続いていることを示す 背景には、AIやautomation（自動化）を使って業務を効率化するという会社の強い方針がある 便利さの裏で、人の仕事がどう変わるのかという不安もいっそう強まっている Amazonが、また人を減らしました。しかも今回は「大規模リストラのあとに一段落」ではなく、AIによる効率化を強めながら、まだ調整を続けているというのがポイントです。Business Insiderによると、今回の削減はAmazonのRetail部門の中でも Selling Partner Services という組織で行われました。 この名前、ちょっとわかりにくいですよね。ざっくり言うと、Amazonのマーケットプレイスで商品を売る第三者の販売者を支えるチ

DomoのチーフデザインオフィサーChris Willis氏は、AIへのFOMO（乗り遅れたくない恐怖）に焦らされるべきではないと語った 企業は「AIを入れること」自体を目的にしがちだが、重要なのは何のために使うかを先に決めること AI導入が「やってる感」の演出、つまりAI theaterになっている会社もある まずは大きな夢より、請求書チェックや表計算の自動化のような小さな業務から始めるべきだという 顧客対応を丸ごと chatbot に置き換える発想には疑問を呈し、人間の判断が必要な場面を見極めるべきと主張している The Registerの記事は、Domoのチーフデザインオフィサーであり futurist（未来予測を担う役割）でもある Chris Willis 氏の発言を中心に、いまのAIブームに対するかなり現実的な見方を紹介しています。 彼の主張をひとことで言うと、「AIで焦るな、まず落ち着け」です。 これ、かなり大事な視点だと思います。というのも、最近のAIは「使わないと出遅れる」「今すぐ導入しないと競争に負ける」という空気が強す

著者は「AIを入れれば業務プロセスが自動的に速くなる」という期待にかなり懐疑的 重要なのは「一番時間がかかる工程」ではなく、「どこで詰まっているか」を見ること ソフトウェア開発は、単にコードを書く作業ではなく、問題を正しく理解して解決策に落とし込む作業 AIはコードを速く書けるかもしれないが、その前提となる仕様の整理や手戻りの説明は省けない 速くしたいなら、人数を増やすより「入力の質を上げる」ほうが効く場合が多い 「遅い工程に人やAIを足すだけでは、プロセスは速くならない。まず上流の詰まりを直そう」 という話です。 これ、かなり大事です。しかも地味に耳が痛い。というのも、組織って何かが遅いと、つい「もっと人を」「もっとAIを」と言いがちなんですよね。でも著者はそこに待ったをかけています。 著者は、最近の多くの組織がprocess optimization（業務プロセス改善）に注目していると書いています。景気が悪いと、会社は新規拡大よりも「今ある仕事をもっと効率よく回す」方向に向かいがちです。これはよくある流れです。 そこに今はAIブームが乗っています。 「AIを入れれば

手作業でやっていた「ニュースソース追加」を、月1回の自動処理に置き換えた まず Firecrawl でランキングページをきれいな Markdown に変換する OpenRouter の無料で使える複数の LLM を順番に試し、ニュースサイトのURLを抽出する さらに web_search ツールでURLの妥当性を確認し、壊れたURLや誤検出を減らす 生成した YAML を重複チェックしたうえで保存し、GitHub Actions が PR を自動作成する マージ後は既存の CI が検証・反映まで行い、ライブダッシュボードにすぐ表示される この記事は、`Source Score` というマイクロサービスの開発を続けている筆者が、「ニュースソースの追加」を自動化した記録です。 最初は、ソースはたった5件を手で追加して動作確認していたそうです。まあ、最初の一歩としてはすごく自然です。システムを作るとき、最初から完璧に自動化しようとすると逆に進まないので、まずは人力で土台を作るのはよくあるやり方です。 でも問題は、その先です。 世界中の主要ニュースサイトを定期的に取り込みたいのに、毎回手作業で

AI agents は、普通の ChatGPT 的な使い方より はるかに多くの tokens を消費しがち その理由は、agent が 考える・試す・失敗する・やり直す を何度も繰り返すから 使った分だけ課金される仕組みでは、成功しても失敗しても請求が増える 実際に、チーム規模が小さい会社でも 予想外の高額請求 が起きている しかも厄介なのは、事前に正確な請求額を予測しにくいこと この記事が扱っているテーマは、いまのAI業界でかなり重要です。 それは 「AI agents は便利だけど、気づかないうちにすごい勢いでお金を使う」 という問題です。 ここでいう AI agent とは、単に質問に答えるAIではなく、 「目的を与えると、自分で手順を考えながら作業を進めるAI」のことです。 たとえば、コードのバグ修正、調査、要約、ファイル操作、タスク分解などを自動でやるタイプですね。 普通のChatGPTの使い方なら、1回の質問で1回の回答が返ってきます。 でもagentは違います。 途中で「どう進めるか」を考え、必要なら何度もツールを呼

Anthropicが Claude Code向けに「Routines」 という新機能を発表 定期実行・API呼び出し・GitHub webhook などで、自動的にコーディング作業を走らせられる cronや自前サーバーを用意しなくても、Claude Codeのクラウド上で動く のがポイント 使い道は、バグの一次切り分け、PR作成、ドキュメント更新、CI失敗の対応 など 便利そうだが、コミュニティでは 信頼性や利用上限 を心配する声もある Anthropicが、Claude Codeに Routines という新機能を追加しました。ざっくり言うと、「決まったタイミング」や「外部イベント」をきっかけに、Claude Codeに作業を自動実行させる仕組みです。 これ、かなり面白いです。というのも、AIコードエージェントってこれまで「人が対話しながら使う」印象が強かったんですよね。でもRoutinesは、その一歩先に行っていて、AIを“会話相手”から“バックグラウンドで働く担当者”に近づける 動きだと思います。 InfoQによると、Rou