何もかもが未知だった頃に比べれば、 戸惑い方は少し変わってきました。
前は、ただ圧倒されていたものが、 今は少しずつ「そういうものなのだ」と受け止められるようになってきた。 文化に適応してきた、ということなのかもしれません。
ただ、慣れてきたからこそ思うのは、 周りに合わせることと、自分をなくすことは違う、ということです。
新しい環境では、まず合わせることが大事になる。 でも、合わせることばかりに意識が向きすぎると、 自分がどう考えるか、自分はどう進めたいかが薄れてしまう気もします。
郷に入っては郷に従え、は大事。 でもそれだけではなくて、 自分なりのスタンスも持っていたい。 そのバランスを探ることが、 これからの課題なのだと思います。
自分が仕事を進める上でこだわっている部分、 本当に必要なのか、ユーザーファースト このあたりを前面に出して楽しんでいけるといいですね。
また、最近あらためて大事だと思うのが、 仕事以外の雑談やコミュニケーションです。
業務の話だけをしていると見えないものが、 少し気を抜いた会話のなかで見えてくることがある。 その人の考え方や温度感がわかるだけで、 仕事のやりやすさも当然変わってきます。
仕事を進めるための関係性というより、 一緒に働く人として知っていくこと。 そういう意味では自分もまだまだ猫を被っているので、 もっとオープンにならなければいけませんね。
適用とスタンス
その両方を意識しながらバランスを取ろうとすることも、 自分らしさなのかもしれません。
自分らしさを大切にしながら、自信を持って進んでいきたいです。
]]>周りはみんなよく働いていて、 自分だけが置いていかれているような気がする。 正直に言えば、気持ちがかなり落ちていて、 少し病みかけていたと思います。
それでも今週は、ようやく 「少しは貢献できたかもしれない」と思える瞬間がありました。 小さくても、形になって見えるものがあると、 それだけでずいぶん救われます。
まだまだ足りない。 でも、まったく何もできていないわけではなかった。 そう思えたことで、ようやく少しだけ安堵しました。
一方で、少し余裕が出てくると、 不思議なくらい『たいせつなもの』をおろそかにしそうになる自分もいます。
あれだけ支えてもらっていたのに、 2週目よりも、そこに費やす時間やありがたみが薄れている気がする。 心が落ちているときほど大切さを痛感するのに、 少し持ち直すと、また忘れそうになる。
なんて愚かなんだろうと思います。
でも、こうして気づけたなら、 まだ立て直せるはず。 余裕がないときだけ大事にするのではなく、 余裕があるときこそ、ちゃんと大事にしたい。
心が戻ってくると、見えなくなるものがある。
大切なものは、苦しいときには見えて、落ち着くと薄れてしまう。
でも本当は、 苦しいときに支えてくれた存在こそ、いちばん忘れてはいけない。 そんな自分を反省しながら、 そのありがたさを行動で返していきたいです。
]]>周りの人たちの働きぶりを見ていても、 「この密度、この進め方がこの会社のスタンダードなんだな」と思う場面が多いです。 その熱量に引っ張られる一方で、 まだ慣れない自分は、プレッシャーで押しつぶされそうになることもあります。
今週ふと考えていたのは、 会社によって仕事の進め方は本当に違う、ということです。
当たり前だと思っていたやり方が通じなかったり、 逆に「そう進めるのか」と驚くこともある。 多かれ少なかれ、びっくりすることは必ずあるのだと思います。
でも、その驚きもずっと続くわけではなくて、 少しずつ背景がわかってくると、見え方が変わってくる。 最初は戸惑いだったものが、 だんだん「このチームらしさ」に見えてくるのがおもしろいところです。
まだまだ全てを理解できているわけではないけれど、 わからないなりに観察して、受け止めて、慣れていく。 今はその途中なのだと思います。
文化は、すぐにはなじめなくて当たり前。
驚いたり戸惑ったりしながらも、 少しずつ「この会社らしさ」が見えてくる。 今はまだ、その途中にいるのだと思います。
]]>正直なところ、息をつく余裕がなくて、 このまま気持ちがすり減ってしまいそうだと感じる日もありました。
そんな中で、あらためて思うのは、 自分にとって今いちばん大切なのは家族だということです。
子どもと一緒に遊べる時間は、 きっと思っている以上に、今だけのもの。 忙しい毎日のなかで、その時間にどれだけ救われているかを実感します。
仕事で張りつめていた気持ちが、 少しだけやわらぐ。 ちゃんと笑える。
忙しいと、目の前のことだけで頭がいっぱいになりがちだけれど、 だからこそ忘れたくないものがある。
たいせつなものは、すぐそばにある。
この時間を当たり前だと思わずに、 ちゃんと大切にしていきたいです。
]]>「まだチームの力になれていないな」と感じる瞬間も多くて、 人間関係や信頼関係も、これから一つずつ積み上げていく段階。
だからこそ、ふとしたタイミングで、 「この選択は本当に良かったのかな……？」 そんな不安や焦りが顔を出すこともあります。
でも、今週あらためて思ったのは、 最短の近道は、じっくり確実に進むことだということ。
わからないことが多い中、すべてを完全に把握することは不可能なので、 一つひとつ学んで、吸収して、次に活かす。 小さくても確実に前進する。
焦って背伸びするより、地に足をつけて積み上げるほうが、 結果的に早く、遠くまで行ける。
急がば回れ。
この言葉を、しばらく自分の合言葉にして進んでいきます。
]]>という用途でブラウザ操作を自動化していました。
テストのために特定のフォームだけ自動入力したりとかね。
しかし最近、Selenium IDE がサポート終了となり Chrome の拡張機能で使えなくなってしまったため、AIちゃんにおすすめされた Playwright を試してみることにしました。
結論から言うと、Selenium IDE 的な使い方もできて満足！
この記事では、
をまとめます。
Node.js が入っていれば、まずはこれだけで試せます。
npx playwright codegen https://example.com
初回は Playwright 本体やブラウザのインストールが走ります。もし途中でエラーが出た場合は、以下を実行してください。
npx playwright install
これで録画モード（codegen）が起動し、操作すると自動でコードが生成されます。
となります。（Selenium IDE も同様）
昔の時代の Selenium IDE は「今見ているページの一部だけ自動化」ができて便利だったのになぁ。。
ということで工夫が必要です。
ここで活躍するのが await page.pause() です。
基本の考え方
実際のコード例
import { test } from '@playwright/test';
test('部分的に自動化する', async ({ page }) => {
// ① まず起動してページを開く
await page.goto('https://example.com');
// ② 手動操作したいところで止める
await page.pause();
// ③ 自動実行したい処理
await page.locator('#submit').click();
await page.locator('#count').fill('3');
// ④ 再び止める（結果確認用）
await page.pause();
});
この状態で
npx playwright test --debug
を実行すると、
という流れになります。旧Selenium IDE の「途中から操作 → 再生」にかなり近い体験ができます。
Playwright は
という設計です。
つまり、
と、ウィンドウが一瞬で閉じてしまいます。
「確認したい」「途中で操作したい」場合は、必ず await page.pause() を入れるのがポイントです。
await page.pause() を使えば途中で止めたり、ページの一部だけ自動化できる旧Selenium IDE に慣れている人ほど、最初は思想の違いに戸惑いますが、pause を使いこなせると一気に世界が変わると感じました。
「ちょっとした自動化」「デバッグ用途」でも Playwright、かなりアリです。
]]>gh コマンドで GitHub の PR を見たい時、サンドボックスのネットワークが遮断されていると失敗します。（以前は不要だったのにいつからかセキュリティ周り厳しくなってました）
下記を追記すればOK！
vi ~/.codex/config.toml
[sandbox_workspace_write]
network_access = true
sandbox_workspace_write セクションで network_access = true にすると、サンドボックスから外部ネットワークへ出られるようになります。gh pr view や gh pr checkout がサンドボックス内で動作するようになります。MCP の追加やコマンド運用の詳細は、別途まとめた記事に置きました。
Codex も Antigravity と同じく、まずサンドボックス設定を整えてから使うのオススメです。 今後も細かいTipsをこの「俺のCodex」に追記していきます。
]]>Ctrl + E
メイン ウィンドウ Editor と Agent Manager を切り替えます。
エージェントマネージャーで
Ctrl + ,
設定を変更したい時に素早くアクセスできます。
生成が途切れた時に、自動で「続き（Continue）」をしてくれる設定です。 長いコードを生成している時などに、途中で止まってしまうのを防いでくれます。
ターミナルコマンドをサンドボックス環境で実行する設定です。 ローカル環境（macOS）への影響を抑え、安全にコマンドを実行させるためにONにしておきます。
サンドボックス内でネットワークリクエストを許可する設定です。
これがOFFだと、npm install や外部APIへのアクセスなどが失敗してしまうため、基本的にはONにしておきます。
成果物（Artifact）のレビューを求めるか。 Agent Decides はタスクの複雑さやユーザーの好みに基づいて、エージェントが自律的に判断します。 基本的には効率よくAIに作業してもらうため、エージェントの自律性を優先しています。
ターミナルコマンドの実行前にユーザーに確認を求めるか。 Always Proceedにして、拒否リストにあるものを除き許可しています。 こちらは予期せぬコマンドを実行される懸念もありますが、サンドボックスで実行されるようになったので安心かなと。
ブラウザでのJavaScript実行時に許可を求めない設定です。 JavaScriptは基本ONでないと多くのサイトが操作できないため、Always Proceedにしています。 セキュリティ的な懸念もそこまで高くないと判断しています。
~/.gemini/antigravity/mcp_config.json
中身こんな感じ。JSONなので最後にカンマあるとエラーになるので編集時注意。
{
"mcpServers": {
"slack": {
},
"notionApi": {
}
}
}
chat:write, channels:history などの権限を付与Bot User OAuth Token (xoxb-...) を取得Team ID (T...) を取得"slack": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-slack"],
"env": {
"SLACK_BOT_TOKEN": "xoxb-xxxx...",
"SLACK_TEAM_ID": "Txxxx..."
}
}
Internal Integration Secret (ntn_...) を取得OPENAPI_MCP_HEADERS にJSON形式で認証情報を渡します。
"notionApi": {
"command": "npx",
"args": ["-y", "@notionhq/notion-mcp-server"],
"env": {
"OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer ntn_xxxx...\", \"Notion-Version\": \"2022-06-28\" }"
}
}
FigmaデスクトップアプリをインストールしてデスクトップMCPサーバーとして実行します。そのためトークンは不要。
Shift + D)Figmaアプリとローカル通信を行う設定になります。
"figma-dev-mode-mcp-server": {
"command": "npx",
"args": [
"mcp-remote",
"http://127.0.0.1:3845/sse"
],
"env": {}
}
Figmaアプリ入れずにリモートMCPサーバーで動作させてみようとしたがイマイチ記法がわからず諦めました。
参考：Figmaの公式ヘルプ
"github-mcp-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server"
],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxx..."
}
}
「開発は PC の前でやるもの」。
そう思っていましたが、最近その前提が崩れ始めています。
理由はシンプルで、AI がコードを書くようになったからです。
この記事では、
という制約下で、
どこまで実用的な開発ができるのかを整理します。
これまでスマホでの開発が現実的でなかった理由は明確です。
要するに 「コードを書く」こと自体がスマホに向いていませんでした。
近年の AI コーディングは、
段階を越えて、タスクを渡すと AI が実装までやるフェーズに入っています。
ここで重要なのは 人間がコードを書かなくてもよくなった 点です。
Codex は、この流れを決定的にした存在です。
ブラウザ上で Codex を使うと、
人間は、
だけでOK。
本記事で扱う「Codex」は ブラウザ上で利用する Codex（Web UI） を指しています。
Codex には CLI ツールとして Codex CLI もありますが、思想と利用体験が大きく異なります。
比較すると以下の通り。
| 項目 | Codex（ブラウザ） | Codex CLI |
|---|---|---|
| 利用形態 | ブラウザ | ターミナル |
| 環境構築 | 不要（自動） | 必要 |
| GitHub連携 | あり | なし（ローカル） |
| 並列タスク | 可能 | 基本不可 |
| スマホ利用 | 可能 | 不可 |
スマホの弱点をすべて回避しています。
スマホでやることはほぼこれだけ。
長文のコード入力は不要です。
Codex の本質的な強みはここにあります。
例：
バグ修正 → Codex A
リファクタ → Codex B
テスト追加 → Codex C
人間 1 人 + AI 複数人 という構図が成立します。
実際に電車内でできることは多いです。
もはやこれは 「開発」ではなく「マネジメント」 に近いです。
スマホで書けるかどうかより、
AI に任せられる範囲が広がったことが本質です。
開発者は「実装する人」から、
方向を決めて結果を判断する人へ移ってきています。
通勤時間に方針を決めてAIに依頼。 出社後に結果をレビューして判断する。
開発の現場は、静かに「書く」から「任せる」へ移りました。
これからの開発者は「実装する人」より「判断する人」になります。
場所は自由、役割は明確。
次に変わるのは、開発者という役割そのものかもしれません。
N+1問題は「親データを取った後、子データを件数分だけ追加で取得してしまう」ことで、SQLが爆増してパフォーマンスが落ちる現象。
特にResourceなどのループ処理でリレーションにアクセスすると、気づかないうちに発生しがちです。
N+1は、リリース後に発覚すると辛いので「起きない仕組み」を作ることが大事。
これまでは開発中にデバッグしてN+1問題が発生していないかSQLチェックしてました。これが地味に面倒で大変。。
Resourceクラス（APIのレスポンス整形層）はループ処理を行うことが多いです。
ここで不用意にリレーションにアクセスすると、データ数分だけSQLが発行されてしまいます。
relationLoaded() を使うことで、
with() してロード済みなら使うという安全な実装になります。
Resource側は「読み込まれていたら使う」だけにしておけば、N+1の温床になりません。これは便利！
if ($user->relationLoaded('books')) {
$books = $user->books;
}
UseCase側で必要なデータだけを効率よく with() しているので、Resource側は安全にそれを参照するだけの構成にできます。
でも毎回 relationLoaded を書くのも手間ですよね。
Laravelデフォルトでそうしておいてほしいですね。そんな機能はないの？
あります！
Laravel 8以降は Model::preventLazyLoading() で「うっかりN+1」を防げます！
これを有効にすると、with() していないリレーションにアクセスした瞬間に例外を投げてくれます。
開発中にN+1を完全に防げるので、超強力。
// AppServiceProvider など
use Illuminate\Database\Eloquent\Model;
public function boot()
{
Model::preventLazyLoading();
}
開発中と書きましたが、もちろん本番も同じ設定しててOKです。
ローカルや開発環境でしっかりテストしていれば、そこで検知できるので、本番で発生したらバグですね！
この2つを使いこなせば、N+1問題とおさらばですね！
寒い冬はしっかり手洗いうがいをして、インフルエンザとN+1問題を防ぎましょう！