はてなブックマーク

私は長い間、毎日Web上に日記を書いています（紙の日記から含めると30年以上は書いています）。 npakaさんが「そらみ と へにへに のゆるふわAI研究所」という漫画連載をしているのを見て、AIに絵日記風のマンガを生成できるとふだんの日記と違う表現ができるかも？と思って、CLIツールenikkiを作りました。 enikkiとは enikkiは、テキストで入力したストーリーから絵日記風のマンガを自動生成するCLIツールです。GoogleのGemini 3を使って、脚本生成から画像生成までを一気通貫で行います。 主な特徴は以下の通りです： 対話型UI: ストーリー、スタイル、コマ数などを対話形式で入力できます 19種類のスタイルプリセット: 4コマ漫画、少年漫画、少女漫画、Webtoon、アメコミなど ステップごとの確認: 脚本・画像それぞれで確認・再生成が可能です キャラクター画像の参照:

はじめに PKSHA Technology のソフトウェアエンジニアの新冨です。 私のチームでは社内問い合わせ管理ソフトウェアである PKSHA AI ヘルプデスクを開発しています。PKSHA AI ヘルプデスクに関する詳しい説明は以下の記事を参考にしてください。 先日、問い合わせ者用の Teams 風なチャット画面を ChatGPT 風なデザインに刷新しました。このプロジェクトで私は主担当エンジニアとして、Cursor と MCP（Model Context Protocol）を中心に複数の AI ツールを統合し、開発サイクル全体を AI フローとして再構築しました。「AI にコードを書かせる」だけでなく、タスク起票から仕様参照、フィードバック反映、QA、PR 作成までを一連の循環として AI に組み込むと、開発の速度と品質が変わりました。 この記事を通して読者が、Cursor と MC

はじめに 普段私たちが利用している Ubuntu などの Linux ディストリビューションは、インストーラーやパッケージマネージャーによって構築、管理が自動化されています。ユーザーが複雑な設定を意識する必要はなくなりますが、その反面、構築、管理として具体的に何が行われているかが見えにくくなっています。 本記事では、Linux From Scratch (LFS) の手順に従い、与えられたソースコードのみから Linux システムを構築します。日本語訳も用意されていますが、それを読んでなお分かりづらい部分があったので、詰まった部分やややこしい部分などを共有しながら、LFS を解説したいと思います。 LFS は、既存ディストロに頼らず、上流のソースコードから Linux システム一式を自分で組み上げてみるためのドキュメントです。本記事はその全手順をなぞるものではなく、特に以下のポイントにフォ

はじめに デジタル化が進む社会において、私たちは頻繁に「従来よりセキュリティが強化されます」という言葉を耳にします。特に行政や金融サービスのデジタル移行に関しては、暗号技術を活用したデジタル鍵によって、物理鍵に比べて圧倒的な安全性が確保できています。それにもかかわらず、多くの人々は「デジタル＝危険」「紙や物理の方が安全」という印象を持ち続けています。この違和感は、単なる知識不足ではなく、人間の心理構造と情報の伝わり方に起因しています。本稿では、なぜ人は「現実と逆の感覚」を抱くのか、その根本理由を掘り下げて考察します。 見える危険は安心し、見えない危険は恐怖になる 人間は、理解できる危険には冷静でいられますが、理解できない危険に対しては強い不安を覚えます。物理鍵には壊すための「手順」が存在し、それを想像することが簡単です。泥棒が工具を持ってきて壊す姿は、映画やドラマでよく描写されるため、イメ

はじめに アジャイルという言葉は広く普及していますが、その本質を正確に理解している人は多くありません。表面的には「変化に強い開発手法」「小さく作って早く回す」という説明が一般的ですが、実際のアジャイルははるかに本質的で、人間の認知能力と組織構造に強く依存した哲学的な方式です。本レポートでは、アジャイルの本質を掘り下げ、なぜ特定の条件を満たすチームでのみ成立するのかを論理的に整理します。そのうえで、アジャイルが成功するために必要な“人の条件”と組織の前提について考察します。 アジャイルとは「真実 × 目的 × 推論」が揃う方式である アジャイルが他の開発方式と決定的に異なるのは、根幹に「真実を操作しない」という前提が置かれている点です。嘘や政治的配慮を最小化し、現実をありのまま扱います。これにより、チーム内の各メンバーが事実を基点として矛盾なく行動できます。しかし、事実の共有だけでは組織は前

なぜSQLのテストが必要なのか ユニットテストでDBアクセスをモックするのは一般的なプラクティスです。テストの高速化に有効ですが、SQLロジック自体はテストされないという課題があります。 複雑なJOINや集計処理、サブクエリを含むSQLは、意図通りに動作しているか実際にRDBで実行してみないとわかりません。また、パフォーマンスチューニングのためにSQLを書き換えたとき、テストがなければ「最適化によって挙動が壊れていないか」を確認するのが困難です。 「シンプルなSQLだけ書いて、複雑な処理はアプリケーション側で行えばよいのでは」という考え方もあるでしょう。しかし、大量のデータをアプリケーション側に持ってきて処理すると、データ転送のオーバーヘッドやインデックスの恩恵を受けられないなどの問題があり、パフォーマンス劣化を起こしがちです。 結局、パフォーマンスを保ちつつ複雑なロジックをテストするには

Claude Codeの登場で学びの時間が減った Claude Codeが便利すぎて、もう手放せません。 ただし、Claude Codeを使えば使うほど「自分でコーディングする機会」は激減しました。 それが悪いとは断言しづらいですが、一つ言えるのは「私のような中途半端にプログラミングを学んだ人間にとって勉強の機会が減ることは致命的」ということです。 Claude Codeの/output-styleでLearningを選ぶことでユーザーの学習をサポートできなくはないのですが、個人的に試した印象としては「身につけるための学習」とはちょっと違うかな？と感じました。 では「身につけるための学習」とはどういった学習か。 これも個人的な意見ですが「反復練習」「能動的な調査・試行錯誤」が非効率的であっても有効だと思っています。 一番勉強していたとき、つまり学生時代を思い返すと「繰り返し問題集を解く」「

はじめに アプリやライブラリ開発時に地味に使える属性について、よく使うものから意外に使えていなかったものなど備忘録代わりに記載します。 デバッグを支援する属性 DebuggerDisplayAttribute デバッガー変数ウィンドウのインスタンスの値表示をカスタマイズできる属性になります。引数に任意の文字列を設定したり、任意のフィールド、プロパティ、メソッドを設定することができるため、うまく使うことでデバッグ時に必要なインスタンスの値を表示することができます。 例えば、以下のIntWrapperクラスを実装した場合、DebuggerDisplayAttributeを追加しない状態だと型名（今回だとIntWrapper）が表示されます。

こんにちは、PortalKey の植森です。 今回は弊社で行っている AI を使った開発ワークフローについて書きたいと思います。 AI コーディング導入の難しさ 皆さん、こう思ったことはないでしょうか？ 「AI にコーディングさせてみたけど使い物にならない」 「これって本当に効率上がってるの？」 ネット上などで見かけるサンプルコードレベルの例を見て「こんなシンプルな例で参考にならない」と感じたり、導入事例を見て「どういう使い方をしたら効率が上がったのかを知りたい」と感じることも多いでしょう。 僕も以前はそう感じていました。 実際のところ、「AI を使えばあらゆるシーンで誰でも効率が上がる」というのは嘘だと思います。 そこで、今回は実際に導入してみて感じた AI コーディングへの課題と自分なりの AI を使った効率的なワークフローについて書きたいと思います。 AI を使った開発ワークフロー

こんにちは。PIVOTでソフトウェアエンジニア、スクラムマスターを務めて(いる|いた)@tawachanです。 この記事では、ソフトウェアエンジニアの役割が「作業者」から「エンジニアリングマネージャー」へ変化する中で、開発プロセスがどう変わったかを共有します。私たちのチームがスクラム寄りの運用からカンバン寄りの運用へ移行した経緯の記録です。 私たちのチームは、もともとアジャイル開発を実践する中で、厳密なスクラムフレームワークに固執するのではなく、常にチームに合う形を模索してきました。Notionのスプリント機能を活用し、各種スクラムイベントを運営するなど、スプリントベースの計画を重視していました。 しかし、AIによる開発支援が現実のものとなり、全員がAIをメンバーに持つエンジニアリングマネージャーというビジョンが掲げられると、働き方の前提が大きく変わります。この記事は、その前提の変化に気づ

こんにちは。PIVOTでソフトウェアエンジニア、スクラムマスターを務めて(いる|いた)@tawachanです。 この記事では、PIVOTのプロダクトチームがNotionからGitHub Projectsへタスク管理ツールを移行した経緯と、具体的な実装方法について紹介します。 背景：AIファーストチームへの変革 詳細な背景については、前回の記事「スクラムからカンバンへの移行——ソフトウェアエンジニアがマネージャーになる時代に」で、チームの思想やプロセスの変化について紹介しました。今回は、その思想を支える具体的なツールの変化に焦点を当てます。 前回の記事で紹介したように、私たちのチームはAI時代の開発に合わせてプロセスを見直し、スプリントベースからカンバン方式へ移行しました。しかし、プロセスを変えるだけでは不十分でした。 開発速度が上がると、次に見えてくるのはツール自体のボトルネックです。特に

今週は、AIコーディング支援ツールの分野で大きな進展がありました。Cursor 2.0の登場により4倍高速なコード生成が可能になり、Claude Codeもサブエージェント機能を強化しました。また、Microsoft ResearchのAgent LightningやMem0など、AIエージェントの能力を拡張する注目のオープンソースプロジェクトも紹介します。 🚀 リリース情報 Cursor 2.0（2025-10-29） Cursorの大型アップデート「2.0」がリリースされました。新しいエージェント型コーディングモデル「Composer」が導入され、同等の知能を持つモデルと比較して4倍高速な動作を実現しています。 主な新機能： Composer: 新しいエージェント型コーディングモデル（同等モデルの4倍高速） マルチエージェントサポート: 最大8つの並列エージェントを同時実行可能 ブラ

AI加速時代におけるQAエンジニアの生存戦略 ― PIVOTでの実践から ビジネス映像メディア「PIVOT」でQAエンジニアをしているケイスケです。 本記事では、AIによる開発工程の加速に直面したとき、QAエンジニアがどのように適応していくか。 そして、PIVOTというプロダクトで実際にどう取り組んでいるのかをお伝えします。 1. はじめに：AIが加速する開発と取り残されるテスト工程 GitHub CopilotやCursor、Claude Codeなど、AIによるコーディング支援が開発スピードを大きく押し上げています。 一方で、QAエンジニアの現場はどうでしょうか？ 開発はAIで加速するのに、テストは依然として手動で遅い。 多くのQAエンジニアが、この「スピードの非対称性」に課題を感じているのではないでしょうか。 私自身もまさにこの課題に直面しました。 特に、開発サイクルが短く・マルチプ

🚀 使い始めたきっかけ 社内運用予定の広告管理システムを開発することになり、TypeScript や React、Hono、TailwindCSS を使うことが決まっていました。 ところが、TypeScript を書いたことがなく、React も Hono も TailwindCSS も触れたことがありません。 そこで、AI にコードを書いてもらう開発をしてみようと思い、Claude Code を使用した開発を行いました。 同期の新卒メンバーも各々、 Claude Code を使って同じ技術スタックで開発を行いました！ 📝 現在の使い方 大まかには以下の流れで使っています。 マークダウンファイルに、やりたいことや要望、決まっている仕様をとにかく書き出す それを元に、Claude Code に仕様書を作成してもらう 仕様書を元に、実装手順書を作成してもらう 実装手順書を元に、コードを書い

はじめに 世の中ではしばしば、情報を「氷山」に例える比喩が使われます。水面上に見えているのはほんの一部であり、大部分は水面下に隠れているという構図です。この考え方は、機密情報を氷山の下に、公開情報を上に置き、見えない部分こそが価値の本質だとみなす発想に結びつきます。 しかし実際の社会では、価値を生むのは「隠された情報」そのものではなく、「見えている情報をどう扱うか」です。つまり、公開情報の読み解きと運用こそが実務で決定的に効きます。 本稿では、なぜ公開情報が機密情報以上に重要なのかを、情報構造・知識形成・理解力という観点から論じ、氷山の上に見えている部分こそが社会における知的競争力の源泉であることを明らかにします。 公開情報の価値は「誰でも理解できる」ものではない 多くの人は「公開されている情報＝誰でも理解できる」と誤解しています。しかし実際には、公開情報を活用できる人は限られています。た

こんにちは。 本記事では、アプリケーションの権限制御の実装でよく用いられる権限モデルと、それらの違いや使い所についてまとめます。 想定読者 権限モデルの種類や概要を知りたい方 RBACは実装したことがあるが、ABACは実装したことがなく、何となくだけ知っている方 ReBACは全く知らなかったのでとりあえず概要を知りたい方　→私です 前提 アプリケーションの権限制御とは、「アプリケーションが管理するリソースに対して、ある主体が行う何らかの操作を許可するか否かを判定する制御」だと考えます。 主体はユーザー単体であることもあれば、グループという形でユーザーの集合である場合もあります。 ECサイトを例にすると、以下のようなケースが考えられます。 顧客は自身の注文情報を閲覧することは許可されるが、他の顧客の注文情報を閲覧することは拒否される 顧客が商品を購入することは許可されるが、商品を作成すること

現実のアプリケーションで発生するすべてのエラー・例外をResult型に変換するのは非現実的 エラーハンドリングが不要なものはUnexpectedErrorとしてまとめてしまう という現実的な落とし所を提案する記事です。 TypeScriptにResult型を導入したくなる理由 TypeScriptのエラーハンドリングは、try…catch文を使うのが基本です。tryブロック内でthrowされた例外はcatchブロックで捕捉されます。 try…catchによるエラーハンドリングには、以下の問題があります。 例外がthrowされる可能性がある関数かどうかが型シグネチャに表れないため、呼び出し時にtry…catchが必要かどうかわからない exceptionVarの型がunknown（設定によってはany）のため、エラーの種類に応じたハンドリングができない try…catchを細かく切って個別に

はじめに Unityは2005年以降、PC、モバイル、コンソール、VR/ARといった幅広いプラットフォームに展開できる強みを持ち、世界で最も普及しているゲームエンジンのひとつとなりました。その開発言語としてC#が用いられていますが、この理由に迫ります。さらにUnityは、ビルド時にC#を直接ネイティブ化するのではなく、C# ⇒ MSIL ⇒ C++ ⇒ マシン語という一見遠回りに見えるプロセスを採用しました。これはIL2CPPと呼ばれる仕組みであり、iOSのJIT禁止ポリシーやクロスプラットフォーム展開と深く関わっています。本稿では、UnityがJavaからC#に至った経緯、C#が「スクリプト」と呼ばれる理由、iOSでのJIT禁止の背景、そしてIL2CPPの合理性を考察します。 なぜ、UnityはJavaを採用しなかったのか？ Unityの開発初期、候補に挙がっていた言語にはJavaも含ま

新しいプロダクトを立ち上げる際、どのようなソフトウェアアーキテクチャを採用するかは重要な意思決定です。これまで先人たちが築き上げてきた代表的なパターンは多くありますが、唯一の正解が存在するわけではありません。プロダクトの目的や市場、組織の性質によって最適解は異なります。 PeopleXで1年半の間に5つのプロダクトを立ち上げた経験をもとに、アーキテクチャ選定の考え方について説明していきます。 目的から出発し、実践との相互フィードバックを重ねる これはアーキテクチャに限らず多くの意思決定に共通しますが、「プロダクトゴールを起点とし、現場からのフィードバックを重ねて実践知化していく」ことが出発点です。 トップダウン型では現場のリアリティや暗黙知が共有されにくく、ボトムアップ型では全体の方向性を見失い、局所最適に陥りがちです。だからこそ、両者の視点を往復しながら「目的志向のアーキテクチャ」を磨く

作ったもの：claude-ops-mcp Claude Codeの操作履歴をMCPサーバーとして提供するツールです。ClaudeCodeが自分で書いた自分のログを、自身で読み返すためのMCPです。 なぜ作ったか Claude Codeがv2になり /rewind コマンドで会話を巻き戻せるのは便利なのですが、根本的にClaude Codeは自身が行った作業の内容を理解（記憶）していないという問題があります。 「え、ちょっと何したの？」という素朴な質問に、自身のログを遡って確認するという機能はなく、あくまで推論で答えてきます。単純に不便なのと、なんだか気の毒になってきました。AIにも自分の記憶を持つ権利があってもいいんじゃないかと。 仕組み Claude Codeは ~/.claude/projects/<projectHash>/<sessionId>.jsonl にセッションログを記録し

背景 ども！池田(ikedadada)です！ シリーズもいよいよRust編です。これまでNode.js、Go、Python、Javaの実装を紹介してきましたが、今回は同じTodo APIの要件をRust（Axum + SQLx + MySQL）で実装するときの構成とキーポイントを整理します。 ソースコード: Rust版の全体像 レイヤ構成は他言語編と同じです。依存は常に内向きで、外側の技術的詳細を中へ漏らしません。 domain: エンティティとリポジトリポート application: ユースケースとトランザクションサービス infrastructure: SQLxによるアダプタ、接続コンテキスト presentation: Axumハンドラ、ミドルウェア、エラーマッピング main.rs: Composition Root（依存解決とルーティング） Rustでは Arc とトレイトオブ

TypeScriptで開発をしていると、APIエラーやバリデーションエラーなど、さまざまなエラーを扱う場面があります。 そんなときに、標準のErrorクラスだけで対応していませんか。 この記事では、カスタムエラーを導入するメリットと、ボイラープレートを減らしてカスタムエラーを楽に定義出来るライブラリを紹介します。 カスタムエラーを作る理由 標準のErrorクラスを使用することで楽にエラーを作成できますが、次のような問題があります。 エラーの種類を区別しづらい 追加の情報（HTTPステータスやエラーコードなど）を持たせづらい メッセージが一貫しない たとえば次のような例を考えてみましょう。 try { throw new Error('User not found'); } catch (error) { if (error.message.includes('not found')) {

はじめに こんにちは！PREVENTで働いているバックエンドエンジニアのとぴ（@topi_log）と申します！ 2024年10月にPREVENTにジョインしてから丸っと1年が経ちました。月日が経つのは早いですね。 良い区切りなので、この1年で読んだ本を振り返りながらまとめました。 読み終わった本たち ざっくりグループ分けしてみました（AIが） それぞれ簡単に読んだ感想も添えていきます。 ビジネス・コンサルティング コンサル一年目が学ぶこと 新人・就活生からベテラン社員まで一生役立つ究極のベーシックスキル30選 コンサルとは無縁ですが、エンジニアの友人が読んでいたので読んでみました。 コンサル関係なく社会人スキルが身につくビジネスバイブル本です。 パワポ作成術は自分には馴染みなかったのでさーっと読みましたが、ショートカットキーを覚えるかどうかで作業効率変わるのは「確かに」と納得したので、自分

はじめに LINEログインしかないサービスのローカル開発のために、開発者全員にLINEアカウントが必要なんていやだ ちょっと変なタイトルですが、普通に真面目な記事です。 AKATSUKIとは？ AKATSUKIは、ソーシャルログインの開発・テストを簡単にするためのMockサーバーです。 主な特徴： Google OAuth 2.0とLINE OAuth 2.0に対応 Docker Composeに数行追加するだけで使用可能 実際のソーシャルサービスに接続せずにログイン処理をパスできる 作ろうと思ったきっかけ ソーシャルログインのアプリのローカル開発時が面倒 例: LINEログインがある場合のチーム開発 開発者ごとにLINEのチャネルを作成 オンボーディングが面倒 開発者全員でLINEのチャネルを共有する 開発者でチャネルの秘匿情報を共有することになる => 退職時に面倒 上記を感じていた当

はじめに 祝！ Java 25 リリース 先日（2025年9月16日），Java 25 がリリースされたことは，Java を愛する皆々様ならご存知のことかと思います。 特に，このバージョンは Java 21 に続く 2 年ぶりの長期サポート（LTS;Long-Term Support）版であり，企業利用においても安心して使えるバージョンとして今後の普及が見込まれています。 前バージョンとの比較や注目の点に関しては，Qiita の方に良い記事がありましたので，そちらをご参照ください。 Java の言語仕様と JVM の仕組みは公開されている ところで，Java のあらゆる言語仕様や Java 仮想マシン（JVM） の仕組みは，JEP（JDK Enhancement Proposal）や JSR（Java Specification Request）などの提案を通じて議論され，最終的に Ope

最近、気がつくとほとんどの時間をターミナルApp上で過ごしていませんか？ IDEを使わないといけない理由がほとんどなくなってきています。 そしてclaude codeをはじめとした最近のCLIツールは何だかUIがいい感じだな！！と思い調べるとinkというライブラリがあるようです。 Claude CodeもGemini CLIもCodexも全部inkが使われているとのこと。凄い。 inkってなに？ inkは、CLIのUIをReactで書けるようにしてくれるライブラリです。 リッチなUI、インタラクティブな操作、リアルタイムな更新など、従来のCLIでは難しかったことがReactの知識で簡単に実現できます。 知らぬ間にinkに本当にお世話になっているわけで、何か貢献しなければという気持ちになります。 作ったもの そこでink-chartというチャート表示コンポーネントを作りました。 CLIでチャ

Parakeet株式会社でResearcherをしている金子(nadare)です。CPUのみで動作するリアルタイムAIボイスチェンジャーのParavoの研究開発をしております。 ParavoはAIモデルをPythonのPyTorchで学習した後、モデルをONNXというフォーマットに変換し、Rust上でONNX Runtimeを用いて動かしています。Paravoは音声変換時に最短で10msごとに推論しており、これの処理間隔や処理時間が短くなるほど、変換した音声をループバック再生する際の遅延が減ってしゃべりやすくなります。また、わずかにでも遅れると音声がプツっと途絶え体験を損ねてしまう問題もあります。そのため、Paravoではモデル推論が高速化するように様々なチューニングに力を入れています。 本記事ではONNXを用いたリアルタイムAIアプリケーションを作成する方向けに、ONNX作成時や推論時の

こちらは primeNumber AI Native Summer Calendarの記事です。 本日の担当は、CTO の kekekenta (@kekekenta) です。 他の記事も読みたい人は カレンダー を見てください！ はじめに 弊社では、業務フローの稟議や申請に Bakuraku を利用しています。たとえば Google Drive の共有ドライブへのユーザー追加なども、Bakurakuを通じて承認しています。 素晴らしいプロダクトで、社内のワークフローを「バクラク」にしてくれる点にはとても満足しています。 一方で、実際の運用ではまだ「完全にバクラク」とは言えない部分も残っています。 今回は、 Bakuraku 上での Google Drive の権限申請について、もっとバクラクにする方法を考えてみました。 まだバクラクになれていないこと Google Drive の申請から