【非エンジニアのためのClaude/ClaudeCodeシリーズ 】 非エンジニアがClaude Codeで定常業務を自動化しようとして気づいたこと

【非エンジニアのためのClaude/ClaudeCodeシリーズ 】 非エンジニアがClaude Codeで定常業務を自動化しようとして気づいたこと

2026.03.20

このシリーズについて

クラスメソッド アカウント営業部の神野(じんの)です。普段はAWSをはじめとしたパブリッククラウドやClaudeをはじめとしたクラウドサービス等のアカウント営業としてお仕事をしています。

この記事は「非エンジニアのためのClaude/Claude Codeシリーズ」の一本です。このシリーズでは、非エンジニア目線でのClaude活用の体験談を発信しています。

私自身このシリーズは二本目ですが、早速うまくいかなかった話を書きます。 「朝夕の定常業務をClaude Codeでまるごと自動化しようとして、あまりうまくいかなかった話」 です。

うまくはいかなかったのですが、その中での気づきは非エンジニアの方にとっても参考になるかな、と思いますので参考までに読んでみていただけると嬉しいです。


やりたかったこと

毎日やっている朝と夕方の定常業務、こんな感じです。

出勤時のルーティン:

  1. KING OF TIME(以下KoT)で出勤打刻
  2. Googleカレンダーで今日の予定を確認
  3. HubSpotと日報(Slack)でチームメンバーの昨日の活動を確認

退勤時のルーティン:

  1. KoTで退勤打刻
  2. Googleカレンダーの予定とHubSpotの活動ログから日報を作成

どれも1つ1つはそこまで大変ではないのですが、毎日繰り返す作業なので「この一連の流れをClaude Codeでまるごと自動化できたら最高だな」と思い立ちました。コマンド一発で、出勤打刻→予定確認→チーム活動チェックまで全部終わっている、という世界観です。


Claude Codeと一緒に作ったもの

Claude Codeに「出勤時と退勤時の定常業務を自動化したい」と相談し、KoTの打刻自動化から着手しました。
何回かやりとりをして内容が決まり、出来上がった構成はこちらです:

kot-agent/
├── agent.py           # メイン(start=出勤 / end=退勤 コマンド)
├── kot.py             # Playwrightでブラウザを自動操作してKoT打刻
├── secrets.py         # 1Password CLIで認証情報を安全に取得
├── calendar_client.py # Google Calendar API連携
├── reporter.py        # Claude APIで日報レポート自動生成
└── SETUP.md           # セットアップ手順(非エンジニア向け)

動作の流れはこうです:

python3 agent.py start

1. 1Password CLIからKoTのID/パスワードを取得
2. Playwrightでブラウザを自動起動し、KoTにログイン
3. 2要素認証が出たら1PasswordのTOTPコードで突破
4. 出勤ボタンをクリック
5. スクリーンショットを保存して完了

勝手にブラウザが立ち上がって、勝手にぬるぬる動いて、すげーっとなりました。ここまで15分くらいしかかかっていません。

スクリーンショット 2026-03-20 7.33.16

Claude Code上の画面としては上記の感じで、ステップごとに勝手に進めてくれていることがわかると思います。

非エンジニアとして「要件を出す」ことの大切さ

少し脱線してしまいますが、作る中で感じた、非エンジニアの方にお伝えしたいエピソードがあります。

Claude Codeに最初に相談した際、認証情報の扱いについて .envファイルにIDとパスワードを直接書く」 という方式を提案してきました。技術的にはシンプルで動くのですが、パスワードが平文でファイルに残るのはセキュリティ的によろしくありません。社内で認証情報の取り扱いについて啓蒙があり、そのリスクは認識していました。そこで「1Password CLIを使って、認証情報はコードに残さないようにしてほしい」とClaudeに指定しました。これは、Claudeが提案してきたものの中で、ユーザーとして守るべきものを判断して修正した事例です。

一方で、ブラウザの自動操作にPlaywrightを使うこと、Google Calendar APIでの予定取得、Claude APIでの日報整形といった技術選定はClaude Codeの提案をそのまま採用しました。正直、Playwrightという名前すら知りませんでしたが、「ブラウザを自動で操作するためのライブラリです」と説明してくれて、納得感がありました。

この経験から感じたのは、技術のことがわからなくても「やりたいこと」と「守らなくてはいけないこと」はユーザー側でちゃんと定義する必要があるということです。「どうやるか」はほぼClaude Codeに任せていいですが、「何をやるか」と「何をしてはいけないか」はしっかり指示する必要があると感じました。
認証情報のところは、少しハードルが高く感じるかもしれませんが、(私もたまたま社内の啓蒙が頭に残っていただけですが)Claudeが提案してくれた方式に対して、「それって一般的なセキュリティの観点で問題ない?脆弱性などのリスクはないか確認してレポートしてください」と言えば、実装前に調べてレポートをしてくれますので、不安に思ったタイミングで都度確認していくことをお勧めします。


翌朝使ってみると、うまくいかない

翌朝、意気揚々とClaude Codeに「勤務開始します!」と宣言したところ、KoTの打刻でエラーが出まくってしまいました。色々壁打ちしながら、原因の特定や代替方法を実施する中で気づきがありました。

1Password CLIの認証が切れて打刻できない

よくよく考えれば、そうだよね、って感じなのですが、1Password CLIは、セキュリティ上の理由でセッションが一定時間で切れます。翌朝に実行すると、1Password CLIのセッションが失効しており、KoTの認証情報が取得できませんでした。

再認証のために op signin を実行しろと言われて、試みましたが、Touch IDや対話的なパスワード入力が必要で、Claude Codeのターミナルからは operation not supported by device というエラーで失敗しました。

❌ 1Password CLIの認証切れ → クレデンシャル取得失敗 → 打刻できない

セキュリティのために1Password CLIを採用したのに、そのセキュリティ機能そのものが自動化の障壁になるという、ある意味当たり前なのですが皮肉な結果でした。

Claude Codeが提案してくれた代替案も失敗

Playwrightでの打刻が失敗したので、Claude Codeに「なんとかならないか?」と相談してみました。すると、Claude Code自体のブラウザ操作機能(Chrome MCP)を使って直接KoTを操作する方法を提案してくれました。ダメだったときに代替案を出してくれるのは、正直とても助かります。

実際に試してみると、Chrome MCPで新しいタブを開き、KoTのページに遷移すること自体は成功しました。ログイン済みの状態でページが表示され、出勤・退勤ボタンの存在もテキストとして確認できました。

しかし、ここで問題が。

  • アクセシビリティツリーにボタンが表示されない:ページ上に「出勤」「退勤」のテキストはあるのに、Claude Codeの検索ツールでは要素として検出できませんでした
  • クリック操作が拒否される:マウス操作を試みると、Cannot access a chrome-extension:// URL of different extension というエラーで、すべての操作が失敗しました

結局、画面は見えているのにボタンが押せない、という状態でした、とClaudeより報告を受け、この方法も頓挫しました。

トラブルシューティングの過程で気づく「手動のほうが早い」

上記2つの問題についてClaude Codeと対話しながらトラブルシューティングを進めていたのですが、Claude Codeは安全性の観点から、コマンド実行のたびにユーザーの承認を求めます。「このコマンドを実行していいですか?」といった確認が毎回表示され、「Yes」をクリックする必要があります。

すべてが順調に流れている時は気にならなかったのですが、 トラブルシューティングで何度もやり取りを繰り返す中で、「あれ、これ自分でKoT開いてボタン押した方が早くない?」 と気づいたのです。

業務プロセス全体を自動化してうまくいっている時には手間に感じなかったのですが、トラブルが起きて1つのタスクにフォーカスした時に初めて感じることができました。(今思えば遅い気もしますが)

ちなみに、最終的にはClaudeからも「自分で押してくれ」と言われるようになりました。笑
スクリーンショット 2026-03-19 7.26.32


振り返り:そもそもClaude Codeに任せる必要があったのか

色々調べていると、1Passwordのデスクトップアプリと1Password CLIを連携させて、都度ユーザーが認証して動かす方法はあるようでした。
うまく動かす方法を考える一方で、冷静に振り返ってみると、今後Claude Codeでの自動化などを考える上での気づきがありました。

そもそも大して工数のかからないものを自動化しても仕方ない

KoTの打刻は、そもそも指定のURLにアクセスして、ボタンを押すだけの30秒くらいの作業です。

こうしたサービスの操作を、わざわざClaude Codeを介して自動化しようとすると、認証の壁・ブラウザ操作の不安定さ・承認クリックの手間が加わり、かえって複雑になります。

そもそも業務負荷が高いわけではないタスクを、無理に自動化する必要はなかったというのが正直な結論です。

「一連の定常業務をまるごと自動化」の理想と現実

「コマンド一発で朝の業務が全部終わる」というコンセプトは魅力的でした。ただ、一連の業務として自動化するには、すべてのステップが安定して動く必要があります。どこか1つでも失敗すると、そこからClaude Codeとの対話的なトラブルシューティングが始まります。

非エンジニアの場合、このトラブルシューティング自体もClaude Codeに相談しながら進めることになるので、何かあった時にかかるコストが、手動でやるコストを大きく上回ります

うまくいけば数十秒の節約、失敗すれば数十分のトラブルシューティング。この非対称性を考えると、朝の定常業務のようなタスクは手動で確実にやった方が合理的かなと個人的には思います。


失敗から得た教訓

今回の失敗は無駄ではありませんでした。むしろ、重要な学びがありました。

1. Claude Codeに任せなくていいタスクの見分け方

今回の経験から、こういうタスクはClaude Codeに任せなくていい、と感じる基準ができました。

  • 認証が必要な外部サービスの操作:そもそもサービス側がすぐ使えるUIを提供している
  • 手動で数分以内に終わるタスク:自動化の恩恵より、セットアップとメンテナンスのコストが上回る

逆に言えば、**「手動だと時間がかかる」「手順が複雑」「ローカルファイルの加工や編集」**というようなところはClaude Codeにお任せする方が良いのかなと思いました。

2. 「やりたいこと」と「守ること」を定義するのは人間の仕事

先述の1Passwordのエピソードに通じますが、Claude Codeは「どうやるか」の提案は非常に優秀です。一方で、「何をやるか」「守らなくてはいけないこと」の定義は人間がやる必要があります。

非エンジニアだからといって、すべてをClaude Code任せにするのではなく、要件と制約を言語化して伝えることが大切です。技術的な知識がなくても、「パスワードは平文で保存したくない」「社内のセキュリティポリシーに準拠したい」といった要件は出せるように普段からそういった情報へのアンテナは張っておくべきだなと感じました。

3. 代替案を出してくれる相談相手として優秀

自動化自体はうまくいきませんでしたが、Claude Codeとのやり取りの過程は有益でした。

Playwrightが動かなくなった時にChrome MCPでの代替案を提案してくれたり、1Password CLIの認証問題に対して環境変数へのフォールバック機構を実装してくれたり。「ダメだった、じゃあこうしてみましょう」という対話ができるのは、一人で黙々と調べて試行錯誤するよりもずっと効率的です。

結果的に打刻の自動化は断念しましたが、「1Password CLI」「Playwright」「Google Calendar API連携」などの技術的な引き出しは増えました。この知識は今後別の場面で活きてくると思います。


まとめ

今回は「朝夕の定常業務をClaude Codeで自動化しようとして、あまりうまくいかなかった話」をお伝えしました。

個人的な結論:認証が絡むWebサービスの操作のように、すでにサービス側が使いやすく設計してくれているタスクは、無理にClaude Codeで自動化しなくていい。

これは「Claude Codeが使えない」という話ではありません。Claude Codeには得意なタスクと、任せなくていいタスクがあるということです。

非エンジニアの方がClaude Codeでの自動化を検討する際に、1つだけ覚えておいていただきたいことがあります。

「うまくいかなかった時のコスト」を想像してみてください。

手動で5分かかる作業なら、自動化が失敗しても5分で終わります。
でも自動化の仕組みが壊れた時のトラブルシューティングは、非エンジニアだと数十分〜数時間かかることがあります。

その非対称性を踏まえて「本当に自動化すべきか?」を判断するのが大事です。

失敗も含めて、非エンジニアの方のClaude活用の参考になれば嬉しいです。


参考情報

この記事をシェアする

FacebookHatena blogX

関連記事