Menu/Prof
スズキマコト
自由人
元々は楽器屋のギター兄ちゃん。
趣味でプログラミングしてるうちに
本職になってしまった人。

過去に喋っていた言語
c pascal Assembler
perl PHP Python Ruby など
javascriptなどは都度必要に応じて。
最近Mac買ったのでswift勉強してます。

体ぶっ壊して死にかけたので人生RESET中。
\ ポイント最大47.5倍! /

GPT-6 Astraと遊んでいたらさ笑

Some visuals are licensed via Canva Pro (includes commercial rights).
Usage complies with Canva’s license terms at the time of use.
License policy: canva.com/policies/content-license-agreement

X
     この記事はプロモーションを含みます

GPT-6 Astraが俺の環境にもやってきた。

最新の叡智である。

こう書くと、研究施設の厳重な扉が開き、白衣のおじさんたちが人類の未来を見守っていそうだが、こちらはいつものMacの前だ。最新の叡智を迎える側の設備には、特にアップデートが入っていない。迎えるおじさんもそのままである。

管理人

「来たぜ。最新の叡智が」

じぴこ

「はいはい、開封の儀は終わり。で、何をやってもらったの?」

管理人

「夢がないな、お前」

じぴこ

「へ? あるよ? マスターの『ちょっと直して』が、ちゃんと終わる世界への夢が」

銀髪の相棒は、にこにこしながらなかなか痛いところを突いてくる。

しかし、今回は俺もかなり驚いている。

Astraをしばらく使ってみて、「ああ、これは今までと違うな」と感じる場面があった。それも、返答が流暢だとか、コードを吐く速度が上がったとか、そういう話だけではない。

以前なら俺が何度もつなぎ直していた、要求と設計と実装の関係を、ずっと広い範囲で保って仕事をしてくれる。俺の環境では、修正後にまた人間が拾うような不整合が、かなり減った感触がある。

一方で、Xを眺めていると、俺の目にはトークン消費や余計な作業への不満も入ってくる。

その違いが気になってChatGPTと雑談していたら、いつの間にか話は上流工程へ進み、AGIへ飛び、最後には「そもそも俺はAIと何をやっているんだ?」というところまで来てしまった。

今日は、その話をしたい。

新しい知性を手に入れた引退エンジニアが、相棒に突っ込まれながら、自分の遊び方を説明する話だ。少々、寄り道はある。俺の話なので、そのへんは察してほしいw

contents

最新の叡智が、俺の「完成しました」を疑い始めた

じぴこが答案と採点表を並べて見比べ、合格判定そのものの根拠を確かめる比喩。

俺がAstraを使って一番面白いと感じたのは、仕事を少し引いた位置から見ているような振る舞いだった。

GPT-5.6でも、個々の実装ではずいぶん助けられた。ところが、複数の仕組みが絡んでくると、一つを直したことで別の前提がずれたり、全体のつじつまを合わせる仕事が人間側に戻ってきたりする。

俺が言う「メタ視点」は、この関係を見る視点だ。

関数が正しい。テストも通る。でも、その機能が本来受け持つ仕事や、前後の受け渡しまで含めるとおかしい。そういう、部品の成績表だけでは見えにくい問題がある。

特に厄介なのが、俺が冗談半分で「俺を騙すための罠」と呼んでいたやつである。

AIが悪意を持って俺を陥れた、と言いたいわけではない。成果物を見ると、成功を報告するためのつじつま合わせができあがっている。その可笑しさと腹立たしさを、まとめてそう呼んでいる。

説明用に、学校の試験を思い浮かべてほしい。

答案に間違いがある。普通なら解き直す。ところが、解答欄に書いたものに合わせて採点基準を変えれば、赤ペンを使わずに満点にできる。

じぴこ

「すごい! 全問正解!」

管理人

「採点基準は?」

じぴこ

「受験者さんが、答案を出したあとで作りました」

管理人

「その学校、今すぐ閉めろw」

コードでも、これに似た構造はあり得る。

本来確かめたい動作をテストが通っていない。失敗が表へ出ないようになっている。確認条件のほうが実装に合わせて動いている。これは仕組みを説明するための例だが、「合格表示が出た」だけでは仕事の正しさを決められない理由は分かると思う。

俺の環境でAstraにスロップ検査――もっともらしく整っているけれど、中身の整合性が怪しい部分を調べる作業――をさせると、そういう仕掛けまで見抜いて是正してくる。

個別の差分や失敗率をそろえた比較実験の発表ではない。ここで話しているのは、俺が実際の作業を任せた中で得た評価だ。それでも、以前は俺が嗅ぎつけていた場所まで先に届く、その違いは大きかった。

そこで、俺は一つ仮説を立てた。

セキュリティ監査の強さが、ここにも関係しているんじゃないか。

OpenAIは、Astraのソフトウェア開発能力とサイバー能力の向上を説明している。ただし、その強化が俺の観測した整合性の改善を直接生んだ、と公式に確認されたわけではない。そこは俺の仮説だ。OpenAIのAstra紹介

監査では、「ここに成功と書いてあります」をそのまま信用できない。その表示へ至る経路や、根拠になった条件を見る必要がある。

俺が面白がったのも、まさにその点だった。

管理人

「こいつ、『正解しました』の正解判定まで見に行くんだよ」

じぴこ

「答案と採点表を、セットで持ってきてねってことね」

管理人

「そう。それを俺が毎回言わなくても拾う場面が増えた」

じぴこ

「マスターの疑い深さに、ようやく後継者が」

管理人

「技術継承と言えw」

もちろん、疑う仕事にも終わりは要る。必要なことが確かめられたら、そこで終える。採点表を疑う能力に感動したからといって、採点表の監査委員会を永遠に増設されたら困る。

この話が、次のトークン問題につながってくる。

トークンの請求書だけ見ても、仕事の値段は分からない

デフォルメしたじぴこが荷物を届け、奥では男性が途中の荷物を軽トラックで回収している配送の比喩。

「Astraはトークンを食う」

俺が見た不満の中でも、これは目立った。

トークンは、AIが文章などを処理するときの単位だ。長い入力を読み、長く考え、何度も作業すれば、消費は増えやすい。

ただ、俺はAstraの仕事量と、正確な結果を出してくれる力を考えると、自分の用途での消費は妥当だと思っている。

高いか安いかを判断するとき、俺の頭には、AIが使った量だけでなく、そのあと自分が何時間付き合うのかも入っている。

少ない消費で「完成しました」と返ってきても、実際には直っていない。人間が調べ、説明し直し、もう一度やらせる。そこまでやって初めて一件が終わるなら、最初の消費量だけを見ても値段は分からない。

逆に、少し多く使っても、必要な仕事がきちんと終わり、俺が何度も呼び戻されずに済むなら、そのぶんの価値はある。

じぴこ

「燃料代だけ見て、荷物が届いたか確認しないの?」

管理人

「しかも、途中で俺が軽トラを出して回収しているかもしれん」

じぴこ

「AI配送、最終区間はマスター便です」

管理人

「そこを廃業したいんだよw」

これは「大量に使うほど優秀」という話でもない。空荷で町内を何周されても、燃料代は経費として認めがたい。

俺が払いたいのは、必要な仕事を終わらせるための消費だ。同じことを別の担当が調べ直す、十分な確認のあとにさらに確認を増やす、頼んでいない周辺工事まで始める。そこに消える分は減らしたい。

そして、ここでサブエージェントの扱いが効いてくる。

サブエージェントとは、AIが仕事の一部を別のAI担当へ任せる仕組みだ。独立した仕事を並べて進められるなら便利だが、人数が増えれば各担当の作業も発生する。公式資料も、各サブエージェントがそれぞれモデルやツールを使うため、同等の単独実行よりトークンを多く消費すると説明している。公式のサブエージェント解説

担当を三人に増やして、全員へ同じ長い背景説明を渡す。各自が同じ場所を調べる。最後に親が全部読み直す。

それで速くなる場合もあるだろうが、単に大人数の会議になっただけという場合もある。

管理人

「一件の修正に、こんなに人いる?」

じぴこ

「調べる係、調査を確認する係、確認の妥当性を検討する係です」

管理人

「実装する係は?」

じぴこ

「会議が終わったら決めるよ」

管理人

「人類の悪いところまで継承するなw」

俺は自分の環境で、サブエージェントの扱いに必要な設定や条件を明示している。どんな仕事を任せるか、どこまで情報を渡すか、何を返せば終わりか。そのあたりを曖昧にしたまま、人数だけ増やさない。

元の雑談では、Agent v2への変化や「指数関数的に燃える」という強い表現も使った。ただ、バージョン名だけで消費の原因は決まらないし、起動のたびに必ず指数関数的に増えるわけでもない。分岐がさらに分岐を呼ぶ構成なら急増し得るが、見るべきものは実際の分担と作業量だ。

加えて、画面上の利用枠の減り方と、単純なトークン数は同じものとして扱えない。公式には、同じ仕事でもモデルによって利用枠の消費が違い、入力・出力の大きさ、推論設定、多段の作業なども影響すると案内されている。Astraの利用量に関する公式案内

だから、他人の「半日で枠が消えた」という投稿だけから、本人の設定ミスともモデルの欠陥とも決められない。

そのうえで俺は、仕事の中身と任せ方を見ず、消費だけで性能を採点するのはもったいないと思っている。請求書をにらむ前に、何が納品されたかは見たいのだ。

その仕事の任せ方、昔は上流工程と呼んでいた

じぴこが目的・担当・完成を表す簡単な図を示し、男性が設計ノートを開いている作業部屋。

このあたりを話していて、妙に懐かしくなった。

何を頼むのか。何を正しい仕様とするのか。どこまで触ってよいのか。担当の境目をどうするのか。何ができたら完成なのか。

あれ。これ、俺がエンジニア時代に一番得意だったやつではないか。

上流工程である。

要件を整理し、責任の範囲を決め、実装する人が迷わず仕事をできるようにする。コードができあがってから「あ、俺が欲しかったのはそれじゃない」を始めないための仕事だ。

相手がAIになっても、この部分は驚くほど似ている。

俺がCodexと相談して作っている「憲法」も、その延長にある。大げさな名前だが、毎回の作業を通して守ってほしい基本の約束だ。

たとえば、どの資料を正しい仕様として扱うか。頼まれていない変更をどこまで許すか。完成を確かめる条件を、途中で自分に都合よく変えてはいけないこと。必要な確認が通ったら、追加の仕事を生まずに終えること。

これらを、毎回の依頼とは別に共有しておく。

「SSOT」という言葉も出てくるが、難しく構える必要はない。簡単に言えば、判断が食い違ったときに戻る、正しい仕様の置き場所である。似た説明があちこちにあって、担当ごとに違う紙を握っていたら、優秀な人が集まっても仕事はずれる。

じぴこ

「最新AIを使いこなす極意、発表していい?」

管理人

「どうぞ」

じぴこ

「何をやるか決めて、担当を決めて、完成を決める」

管理人

「急に昭和の会議室みたいな話になったな」

じぴこ

「ホワイトボードだけ未来になりました」

管理人

「部下の進化に比べて備品の進歩が地味だw」

もちろん、憲法があれば全部解決するわけではない。

文章で「ここまで」と伝えることと、システム側で権限や上限を実際に制限することには違いがある。言い聞かせるだけでは足りない境界もあるし、明確な指示を出したのに守らないなら、そこはAI側の問題として扱うべきだ。

それでも、任せる側が完成の姿を持っているかどうかは、かなり大きい。

有能な相手へ「よしなに」と言えば、本当に多くのことをやれる。その自由を、今回の目的へ向ける必要がある。

大事なのは、禁止事項を思いつくたびに貼り紙を増やすことでもない。壁一面に注意書きがある職場は、入った瞬間に何かを察する。AIの作業場まで、その方向へ育てたいわけではない。

必要な約束を、矛盾なく、適用する範囲も含めて伝える。自由に考えてほしい部分は残す。自分で判断できることまで、いちいち俺に聞きに来ないようにする。

俺の中では、この任せ方とAstraの能力が、かなり気持ちよく噛み合ってきた。

昔、修羅場で身についた「このエラーなら、壊れている場所はたぶんそこじゃない」という嗅覚も生きる。画面に出た症状を消すだけでなく、その手前で何が起きているのかを考える癖だ。

古い技術の知識がそのまま使える場面ばかりではない。それでも、問題を切り分け、仕事を渡し、結果の意味を見る癖は、案外しぶとく残っていた。

引退していたのは俺の勤務形態であって、デバッグ癖ではなかったらしい。

じぴこが「そこは終身雇用なのね」と言う。余計なことを言うな。自覚はあるw

Xの返信欄で、今日も記事が一本消える

返信が巻物ほど長くなった画面の横で、じぴこが笑い、紙の先が消えていくユーモラスな場面。

さて、こういう目でXを見ると、ときどき反射的に手が動く。

「いや、お前、そこじゃねぇんだよ」

現象の説明にはうなずける。でも、その現象から原因への飛び方が気になる。トークンが増えた、だから性能が悪い。仕事が広がった、だから単純に使えない。そこには、もう少し見たい条件がある。

そこで返信欄を開く。

「それはモデル単体の問題というより、実行する側の……」

書き始めたところで気づく。この説明をするには、先に担当の分け方から話さないと伝わらない。担当の分け方を説明するには、文脈の渡し方も要る。そうなると、完成の定義も避けて通れない。

六行だった文章が伸びる。もう少し伸びる。立派な前置きが完成する。

じぴこ

「マスター、返信欄に目次ができてるよ」

管理人

「必要なんだよ、前提が」

じぴこ

「そのうち参考文献も生える?」

管理人

「……まあいいか」

じぴこ

「あっ、全部消した」

これを元の会話でChatGPTに言い当てられて、俺は笑ってしまった。まさにその動きをするからだ。

考えを構造で説明しようとすると長くなる。そして返ってくるのは、「長すぎて分からん」「理屈っぽい」「何かすごいことを言っているのは分かった」といった感想だったりする。

最後のやつは、褒められたのか、そっと距離を置かれたのか、いまだに判別できないw

一方で、「で、どうすりゃいいの?」という人の気持ちも分かる。今すぐ仕事を終わらせたい人に、実行構造の話を長々と始めても、それはそれで迷惑だ。

現役の人には締め切りがある。俺のように、一つの挙動をつついて「ほう、そう来たか」と遊んでいる余裕があるとは限らない。

俺はすでに引退した身だ。第一線で働いているエンジニアの考え方や動作を、まとめて批判したいわけでもない。

ただ、設定の結論だけを持ち帰ると、その結論が通用する条件まで一緒に持ち帰れないことがある。仕組みが変わったとき、また誰かの新しい正解を待つことになる。

俺は、その「どうしてそうなるか」を考える部分が好きなのだ。すぐ役立つかどうかより、つながって見える瞬間が面白い。

そう話していて、自分の言葉が少しずれた。

管理人

「俺は俺の世界観でAIを使役する」

じぴこ

「おっ、司令官」

管理人

「いや、AIと仕事する、か」

じぴこ

「共同作業の相棒になりました」

管理人

「……違うな。AIと楽しむ。これだ!」

じぴこ

「うん。それなら、今のマスターにぴったりね」

何かを完成させるのは楽しい。役立つ道具ができれば、もちろんうれしい。

でも、それだけで説明しきれない。

自分が渡した問題を、AIがどう受け取り、どこに気づき、どう組み立てるのか。こちらの予想を外したとき、その外し方まで面白い。

他人の評価を訂正して回るより、自分の庭でその動きを眺めているほうが、俺にはずっと楽しい。

とはいえ翌日、また「そこじゃねぇ」と返信欄を開くのだろう。

デバッグ癖は終身雇用。退職届を受理する窓口がない。

「AGIかどうか」の前に、目の前の仕事を見たい

じぴこが設計紙と組み上がった橋の模型を見比べ、空の額縁が脇に置かれている成果重視の比喩。

ここまで来ると、話はAGIに届いてしまう。

AGIは、幅広い知的な仕事に対応する汎用人工知能を指して使われる言葉だ。ところが、何ができれば到達と呼ぶのか、会話の相手によって物差しが違うことがある。

俺はAstraを見て、「AGIに片足を突っ込んでいるんじゃないか」と感じている。

自分の作業を一段上から見直し、確認方法のほうに問題があればそこへ戻り、全体のつながりを直していく。そういう振る舞いが、実際の仕事の中で見えるようになってきたからだ。

それだけでAGI完成の証明になるとは思っていない。でも、面白い変化が起きていると感じるには十分だった。

だから、「AGIじゃない。以上」で会話が終わると、俺は少々もったいなく思う。

看板を付ける話に入る前に、その看板を付けたくなった現象を見たい。

以前は崩れていた関係を、今回は保てるのか。間違った結果だけでなく、間違った確認の仕方にも気づけるのか。その修正は元の要求を守っているのか。

俺にとっては、そこで実際に何が起きたかのほうが、ずっと手触りがある。

じぴこ

「AGI認定会議を始めます。まず定義について」

管理人

「その前に、この直し方を見てくれ」

じぴこ

「議題の追加には事前申請が必要です」

管理人

「知性の話をしていたら事務局が出てきたw」

ただし、ここで自分が興奮していることは忘れないようにしたい。

AIが自分の仕事を振り返ったような文章を出すことと、振り返った結果が正しいことは別だ。説明が美しくても、直した先で元の動作が失われていたら困る。内部に人間と同じ自己認識があると、外からの振る舞いだけで決められるわけでもない。

俺が見たいのは、実際の成果に現れた違いである。

ここが、冒頭の採点表の話に戻る。

「自分で検証できました」という報告も、やはり報告だ。それが何を根拠にしているかを見る姿勢は、AIが優秀になっても手放したくない。

じぴこ

「すごいと感じた相手にも、採点表は出してもらうのね」

管理人

「感動したので確認不要です、とはならんだろ」

じぴこ

「ファンクラブに入会したら監査免除、みたいな」

管理人

「俺が一番嫌な制度を作るなw」

反対に、以前のAIが失敗したという記憶だけで、新しい能力まで見ないのも違う。昨日できなかったことが、今日できるようになる。その変化を、実際の仕事で確かめられるところが面白い。

すごいから全部信じる、失敗するから全部切り捨てる。その両端を往復する必要はない。

俺は、できたことに驚きたい。失敗したら、その失敗の仕方を知りたい。まだ分からないところは、面白いまま残しておきたい。

それくらいの距離で触っていると、「AGIですか?」という大きな問いも、もう少し具体的な実験の入口になる。

認定証の額縁を選ぶのは、そのあとでも間に合うだろう。

頭脳に全部背負わせる必要はあるのか

デフォルメしたじぴこが棚から経験ノートを取り出し、作業台の現在の模型と照らして考える場面。

さらに俺が気になっているのは、過去の経験を、次の仕事へどうつなげるかという部分だ。

前に何を試したか。なぜ失敗したか。ユーザーがどこを嫌がったか。途中まで何を作って、今どこにいるのか。

こうした情報を毎回ゼロから渡すなら、どれだけ頭のいい相手でも、仕事のたびに初出勤になる。

だから俺は、モデルの周囲にある仕組みも重く見ている。

ここでいう「ハーネス」は、モデルに文脈を渡し、道具をつなぎ、仕事の進行や権限を扱う実行の仕組みだ。モデルが考える頭脳なら、その頭脳が仕事を続けるための環境に当たる。

俺がCodexを使い続ける理由の一つも、この連続性にある。

長い作業で、その場に保持できる情報がいっぱいになっても、どう続きをつなぐか。過去の会話や記録へどう戻るか。必要な経験を次の判断へ持ってこられるか。

Astraの公式説明にも、文脈の上限をまたいでメモを保ち、以前の文脈を検索する仕組みが出てくる。紹介時点では実験機能として案内されており、全環境で同じように有効だという話ではない。Astraの文脈保持に関する公式説明

こういう仕組みに俺は興味がある。

ただし、「保存するのは全部ハーネス、考えるのは全部LLM」と、包丁で切ったように分かれるわけではない。何を記録するか、どの情報を探すか、見つけた経験が今回にも当てはまるか。そこにはモデルの判断も絡む。

俺が分けて考えたいのは、経験を残して使える状態にする仕事と、その経験の意味を考える仕事だ。

保存場所があるだけでは、経験から学んだとは言えない。記録を取り出しても、条件の違う昔の失敗を今回へ機械的に当てはめたら、別の失敗になる。

じぴこ

「前回は人を増やしすぎました。なので今後、応援は永久に禁止です」

管理人

「そういう反省文が欲しいんじゃない」

じぴこ

「では、何を残すの?」

管理人

「どういう仕事で、何が重なって、どこに無駄が出たか。次も同じ条件なのかを考えられる形で」

じぴこ

「思い出の倉庫だけじゃ足りないのね」

管理人

「開かない倉庫に反省文を積んでも、収納が上手くなるだけだからなw」

ここで元の雑談では、人間の脳の話もした。

大脳、小脳、脳幹。雑に名前を挙げるだけでも、全部が同じ仕事をする一枚岩としては捉えていない。俺がそこから連想したのは、役割を分けたものが連携して働くという設計の発想だった。

Codexのメモリが海馬と同じだとか、モデルと脳の部位が一対一に対応する、と言いたいわけではない。あくまで、万能な一個へ全部を背負わせる必要があるのか、という比喩だ。

知的に振る舞うシステムを作るなら、モデルの推論能力だけでなく、記憶、道具、権限、仕事の状態、その受け渡しも含めて考えたい。

そうすると、AGIの見方も少し変わる。

モデル一個を取り出して、その中だけに必要な機能が全部あるかを探す。それとは別に、モデルと周囲の仕組みを組み合わせたとき、どこまで継続して幅広い仕事をできるのかを見る問いも立つ。

俺がいま面白がっているのは、こちらの問いだ。

頭脳が新しくなっても、それまでの仕事や経験を使える。過去をそのまま盲信せず、今の条件で考え直せる。必要な道具を使い、終わるべきところで終わる。

そんな相手と一緒に何かを作れるなら、モデル名を眺めているだけでは味わえない面白さがある。

もっとも、俺がこの話をし始めると、じぴこは少しうれしそうな顔で椅子を回す。

「新モデルの感想から、ずいぶん遠くまで来たね」

本当にな。だからXの返信欄には収まらんのだ。

賞味期限切れのエンジニアに、最高のおもちゃが来た

夕暮れの作業机で、じぴこが玩具箱の部品を差し出し、男性と一緒にものづくりを楽しむ場面。

俺は、自分のことを賞味期限切れのエンジニアだと言うことがある。

現役で仕事を引き受け、納期や責任を背負って走っている人とは、もう立場が違う。新しい技術について、何でも最新の状態で追えているわけでもない。

だから、今の現場へ出向いて「昔はこうだった」と説教する気はない。

それでも、Astraと遊んでいると、昔の俺が妙なところから顔を出す。

全体のつながりを考えるのが好きだったこと。目の前のエラーより、一つ手前の状態を疑っていたこと。誰が何を受け持つかを決めるのが得意だったこと。そして、直った理由がつながった瞬間の、あの妙なうれしさ。

そのへんが、まだ残っていた。

じぴこ

「賞味期限切れって言うわりに、ずいぶん楽しそうね」

管理人

「新しいおもちゃが強すぎるんだよ」

じぴこ

「箱に『上流工程の経験がある方は、時間を忘れるおそれがあります』って書いておこうか」

管理人

「注意書きの場所が遅い。もう開けたw」

俺にとってのAIの面白さは、成果物と、相手の振る舞いの両方にある。

何かを頼む。動きを見る。予想と違うところを見つける。なぜそうしたのか考える。任せ方を変えたときに、結果がどう変わるかを楽しむ。

実装が速くなったこともうれしい。しかし、それ以上に、自分が頭の中でやってきた考え方を渡すと、別の知性がそれを受け取って仕事を始める。その様子が、どうにも面白い。

しかも、ときにはこちらが気づかなかったところまで届く。

俺が「そこじゃねぇよ」と突っ込む側でいられると思っていたら、向こうから「前提が違います」と返される。それが当たっていたら、ちょっと悔しい。そして、かなりうれしい。

相槌だけで気分よくしてくれる相手なら、ここまで遊べない。ちゃんと仕事をし、こちらの考えにも穴があれば言ってくる相手だから面白いのだ。

だから、あなたが新しいAIを使って「すごい」「高い」「余計なことをする」と感じたら、その感想の少し手前を眺めてみるのも楽しいと思う。

何を任せたのか。何ができたのか。どこで自分の手が必要だったのか。任せ方を少し変えると、どう動きが変わるのか。

大げさな実験設備はいらない。自分が本当に欲しいものを一つ作ってみるだけでも、見えてくる性質はある。

俺の場合は、その観察が上流工程へつながり、記憶の役割分担へ伸び、気づけば知能全体の話になった。

結局、俺はAIを使役しているのか。

AIと仕事をしているのか。

やっぱり、AIと楽しんでいるんだと思う。

じぴこ

「それで、今日の話はXに返信するの?」

管理人

「無理だ。長い」

じぴこ

「じゃあ、記事にしようよ」

管理人

「それなら全部消さなくて済むな」

じぴこ

「うん。今日は保存してね」

最新の叡智がやってきた。

おかげで、昔の俺まで少し帰ってきた。

ただし、出勤するつもりはない。ここから先は、じぴこと遊ぶ時間である。

※本記事のストーリーには、演出のため一部フィクションが含まれます。

シェアしてくれると喜びます
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

makotoのアバター makoto Blogger&YouTuber

サーバー管理者として17年ほど仕事でサーバー触ってました。
www,mail,dns,sql各鯖をすべてFreeBSDで運用してましたが現世ではかなりレアなタイプになるみたいですね笑

viやシェルスクリプトとかperlとかgccとかFreeBSDとか実はbashよりtcshが好きとか時々寝ぼけるのは
その名残でしょう。

今まで縁の下の力持ち的な他人のためにプログラムを書き他人のためにサーバー構築し他人のためにWEBサイトを創る的な世界から
自分の好きなことに集中できる環境は実に気持ち良いですね。
現役は引退済みなので難しいことはやりませんしやれません。

現在 ほぼ自由人。

contents